devil-linux-develop Mailing List for Devil-Linux (Page 53)

Friedrich Lobenstock wrote:
> Friedrich Lobenstock wrote on 14.05.2006 00:18 MET:
> 
>> Thomas Eder wrote on 13.05.2006 22:23 MET:
>>
>>> is this a feature or a bug?
>>>
>>> user@devil-linux:/home $ /usr/sbin/ping ping.inode.at
>>> ping: icmp open socket: Operation not permitted
>>>
>>> I hope its a bug ;-)
>>
>>
>> Hmmmm....we seem to be missing the setuid flag. Will take a look.
> 
> 
> Can't connect to "my" development machine, so I can't check in the fix yet.
> 

sorry, the "human reset" for your development machine isn't reachable!

I'll try my best!

-- 
thomas

Friedrich Lobenstock wrote on 14.05.2006 00:18 MET:
> Thomas Eder wrote on 13.05.2006 22:23 MET:
> 
>> is this a feature or a bug?
>>
>> user@devil-linux:/home $ /usr/sbin/ping ping.inode.at
>> ping: icmp open socket: Operation not permitted
>>
>> I hope its a bug ;-)
> 
> Hmmmm....we seem to be missing the setuid flag. Will take a look.

Can't connect to "my" development machine, so I can't check in the fix yet.

-- 
MfG / Regards
Friedrich Lobenstock
____________________________________________________________________
Friedrich Lobenstock                       Linux Services Lobenstock
URL: http://www.lsl.at/                         Email: fl...@fl...
____________________________________________________________________

---------------------------- Original Message ----------------------------
Subject: SUBJECT: SourceForge.net: CVS service offering changes
From:    "SourceForge.net Team" <no...@so...>
Date:    Thu, May 11, 2006 18:27
To:      he...@zu...
--------------------------------------------------------------------------

Greetings,

You are receiving this mail because you are a project admin for
a SourceForge.net-hosted project. One of our primary services,
CVS, suffered a series of interrelated, critical hardware failures
in recent weeks. We understand how frustrating this CVS outage
must be to you and your users; however, our top priority remains
preservation of the integrity of your data.

The series of CVS hardware failures prompted us to expedite the
deployment of planed improvements to our CVS infrastructure,
drawing upon much of the knowledge that we gained from our
Subversion deployment. Our improved CVS service architecture,
which we plan to deploy tomorrow afternoon (2006-05-12), will
offer greater performance and stability and will eliminate several
single points of failure.

The Site Status page (https://www.sf.net/docs/A04) will be
updated as soon as the new infrastructure is rolled out. In the
interim, please read the important information provided below
to learn about how these changes will affect your project.


Summary of changes, effective 2006-05-12:


1. Hostname for CVS service

Old: cvs.sourceforge.net

New: PROJECT_UNIX_NAME.cvs.sourceforge.net

This change will require new working copies to be checked out of all
repositories (so control files in the working copy will point to the
right place). We will be updating the instructions we supply, but
instructions that your team has written within documentation, etc. will
need to be updated.

cvs -d:pserver:ano...@cv...:/cvsroot/gaim co gaim

would be changed to

cvs -d:pserver:ano...@ga...:/cvsroot/gaim co gaim



2. ViewCVS

We are moving from ViewCVS to its successor, ViewVC. ViewVC is
currently in use for our Subversion service.



3. Sync delay

Old: CVS pserver, tarballs and ViewCVS provided against a separate
server which is a minimum of three hours behind developer CVS.

New: ViewVC will be provided against developer CVS (it will be current).
CVS pserver will be provided against a secondary server (not developer
server) with a maximum expected delay of two hours.

Follow-up work is planned (this infrastructure takes us 80% of the way)
to essentially eliminate the sync delay.



4. Read-only rsync service

As a new service offering, we are now providing read-only rsync access
against developer CVS. This allows projects to efficiently make
on-demand backups of their entire CVS repository.

All projects should be making regular backups of their CVS repository
contents using this service.



5. Nightly tarball service

Nightly tarball service is being dropped in lieu of read-only rsync
service. Projects which currently depend on nightly tarballs for
repository backups will need to begin using rsync to make a backup copy
of their repository contents.

We see this as a major functional improvement. For a number of reasons,
tarballs have fallen out of sync with the data in the repository at
times in the past few years. Tarballs required a substantial amount of
additional disk, and I/O to generate. The move to read-only rsync
allows backups to be produced on-demand, with an update frequency chosen
by the project.



6. Points of failure

In the past, developer CVS service for all projects was provided from a
single host. CVS pserver service was provided from individual backend
heads based on a split of the data.

Under our new design, developer CVS and most of our CVS-related services
are provided from one of ten CVS hosts (count subject to increase with
growth). Each host is independent, and makes a backup copy of the
repository data of another host (which is used to provide the pserver
CVS service).

Failure of a single host will impact only the availability of data on
that host. Since the data is split among a larger number of hosts, the
size of data impacted by an individual host outage is substantially
smaller, and the time required for us to restore service will be
substantially shorter.

This rapid architecture change has been made possible specifically using
the research we performed for our recent launch of Subversion service.
We've applied our best practices, produced a substantial amount of
internal documentation, and kept an eye toward maintainability.
This effort has allowed us to deploy this new architecture quickly
once hardware was received, and will permit us to quickly scale
this service horizontally as growth and demand requires.



Many other minor improvements have also been made to improve the service
offering and make it less trouble-prone. The most important of which are
listed above. For a full description of the new service offering, and
for information on how to use the services described above, please refer
to the site documentation for the CVS service after the service has been
launched: https://www.sf.net/docs/E04


Thank you,

The SourceForge.net Team

.


-- 

Regards
  Heiko Zuerker
  http://www.devil-linux.org

Thomas Eder wrote on 13.05.2006 22:23 MET:
> 
> is this a feature or a bug?
> 
> user@devil-linux:/home $ /usr/sbin/ping ping.inode.at
> ping: icmp open socket: Operation not permitted
> 
> I hope its a bug ;-)

Hmmmm....we seem to be missing the setuid flag. Will take a look.

-- 
MfG / Regards
Friedrich Lobenstock
____________________________________________________________________
Friedrich Lobenstock                       Linux Services Lobenstock
URL: http://www.lsl.at/                         Email: fl...@fl...
____________________________________________________________________

hi,

is this a feature or a bug?

user@devil-linux:/home $ /usr/sbin/ping ping.inode.at
ping: icmp open socket: Operation not permitted

I hope its a bug ;-)

-- 
regards
    thomas

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Howdy folks !

don't forgett it's Tequila and Corona Day (cinco de mayo)!

But even better:
I'm proud to announce that Dr. Alberto Benati from Italy decided to join
the DL team.

- -- 

Regards
  Heiko Zuerker
  http://www.devil-linux.org

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iEUEARECAAYFAkRbmTwACgkQUcytMSbs+YUbsgCWNIPNbcXBWkfzHnMbFzJn3YLY
/QCeOOu/a4ZPrz/uw+CHv/c3gayZ9FE=
=5lm1
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Thu, May 4, 2006 12:47, Bruce Smith wrote:
>> Take a look at this code fragment from config/etc/initrd/linuxrc (DL
>> 1.2
>> branch), especially the IF at the end: ------------------------ CODE
>> ------------------------
>> echo -e "Please insert Configuration Media and press 'ENTER'" read ANS fi
>> echo done unset ANS RET
>>
>> echo $DL_CONFIG_SOURCE > /shm/DL_CONFIG_SOURCE echo $DL_CONFIG_FILE >
>> /shm/DL_CONFIG_FILE
>> export DL_CONFIG_SOURCE export DL_CONFIG_FILE
>>
>> mkdir -p /shm/root
>>
>> # check if the DL ISO got upgraded
>> if [ -e /shm/dl_iso_replaced ]; then cd /cdrom #change to new root
>> pivot_root . initrd $RED
>> echo "Rebooting..." $NORMAL
>> exec /usr/sbin/chroot . /sbin/reboot -f fi ------------------------ /CODE
>> ------------------------
>>
>>
>> My conclusions regarding the IF are:
>>
>>
>> * old and not used anymore as reboot's after an upgrade
>> are (currently) handled by mount_cdrom
>>
>> * reboot doesn't work anyway - see attachment
>>
>
> I Looked at mount_cdrom, which is the only place I can find that does a
> "touch /shm/dl_iso_replaced", and it does a reboot right after the
> touch.  So I'd say you are correct that the IF will never be true.
>
>> So I'd say I remove the IF completely. Objections?
>>
>
> No objection from me.

Nope

- -- 

Regards
  Heiko Zuerker
  http://www.devil-linux.org

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iEYEARECAAYFAkRanXQACgkQUcytMSbs+YVEpACgnEbvR7WdUOJKKevx58vDE42V
LqcAnA9EIjgHMaexqZ4ShiMeD8XhBERo
=L5wD
-----END PGP SIGNATURE-----

> Take a look at this code fragment from config/etc/initrd/linuxrc (DL 1.2 
> branch), especially the IF at the end:
> ------------------------ CODE ------------------------
>              echo -e "Please insert Configuration Media and press 'ENTER'"
>              read ANS
>          fi
>          echo
> done
> unset ANS RET
> 
> echo $DL_CONFIG_SOURCE > /shm/DL_CONFIG_SOURCE
> echo $DL_CONFIG_FILE > /shm/DL_CONFIG_FILE
> export DL_CONFIG_SOURCE
> export DL_CONFIG_FILE
> 
> mkdir -p /shm/root
> 
> # check if the DL ISO got upgraded
> if [ -e /shm/dl_iso_replaced ]; then
>      cd /cdrom
>      #change to new root
>      pivot_root . initrd
>      $RED
>      echo "Rebooting..."
>      $NORMAL
>      exec /usr/sbin/chroot . /sbin/reboot -f
> fi
> ------------------------ /CODE ------------------------
> 
> My conclusions regarding the IF are:
> 
>   * old and not used anymore as reboot's after an upgrade
>     are (currently) handled by mount_cdrom
> 
>   * reboot doesn't work anyway - see attachment

I Looked at mount_cdrom, which is the only place I can find that does a
"touch /shm/dl_iso_replaced", and it does a reboot right after the
touch.  So I'd say you are correct that the IF will never be true.

> So I'd say I remove the IF completely. Objections?

No objection from me.

 - BS

Hello!

Take a look at this code fragment from config/etc/initrd/linuxrc (DL 1.2 
branch), especially the IF at the end:
------------------------ CODE ------------------------
             echo -e "Please insert Configuration Media and press 'ENTER'"
             read ANS
         fi
         echo
done
unset ANS RET

echo $DL_CONFIG_SOURCE > /shm/DL_CONFIG_SOURCE
echo $DL_CONFIG_FILE > /shm/DL_CONFIG_FILE
export DL_CONFIG_SOURCE
export DL_CONFIG_FILE

mkdir -p /shm/root

# check if the DL ISO got upgraded
if [ -e /shm/dl_iso_replaced ]; then
     cd /cdrom
     #change to new root
     pivot_root . initrd
     $RED
     echo "Rebooting..."
     $NORMAL
     exec /usr/sbin/chroot . /sbin/reboot -f
fi
------------------------ /CODE ------------------------

My conclusions regarding the IF are:

  * old and not used anymore as reboot's after an upgrade
    are (currently) handled by mount_cdrom

  * reboot doesn't work anyway - see attachment

So I'd say I remove the IF completely. Objections?

-- 
MfG / Regards
Friedrich Lobenstock
____________________________________________________________________
Friedrich Lobenstock                       Linux Services Lobenstock
URL: http://www.lsl.at/                         Email: fl...@fl...
____________________________________________________________________

Howdy folks,

I uploaded a new lfssystem for DL 1.3, please use this one from now on.
Main change is it's now a LFS 6.1.1 and uses different libc headers.

-- 

Regards
  Heiko Zuerker
  http://www.devil-linux.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hey,

unfortunately SF has issues with the CVS servers on a regular basis.
The solution is always the same, wait a couple hours to a couple of days
(worst case).

There's an easy way to get access via SSH, join DL as a developer. ;-)

On Mon, April 24, 2006 07:41, "Rudner, Björn" wrote:
> Hello,
>
>
> since a few weeks I try to build a custom DL build for my needs, which
> worked out fine the first time.
>
> Now I'm about to go productive with my changes and wanted to upgrade my
> local lfssystem to reflect the last changes.
>
> But since a few days there seems to be no way to update the local CVS
> from sf.net using:
>
> cvs -d:pserver:ano...@cv...:/cvsroot/devil-linux login
> returns cvs [login aborted]: end of file from server (consult above
> messages if any)
>
> investigations on sf.net turned out that the anonymous servers are down.
>
> using ssh with my sf.net-account worked to connect the cvs but there are
> no rights to download :-(
>
> are there any other ways to download the latests scripts for DL-release
> 1.2 ???
>
>
>
>
> Mit freundlichen Grüssen
>
>
> Björn Rudner
>
>
> ____________________________________________
> Björn Rudner
> Systemadministrator
>
>
> baulogis GmbH Zamdorfer Strasse 100
> 81677 München
>
>
> Telefon	+49 (89) 930 839-16
> Telefax	+49 1805 456 987-200 16
> Mobil		+49 151 12 16 23 71
> E-Mail 	br...@ba...
> http://www.baulogis.com/
>
>
>
> _________________________________________________________________________
> ___
>
>
> Der Inhalt dieser E-Mail ist vertraulich und ausschließlich für den
> bezeichneten Adressaten (dev...@li...)
> bestimmt. Wenn Sie nicht der vorgesehene Adressat dieser E-Mail oder
> dessen Vertreter sein sollten, so beachten Sie bitte, dass jede Form der
> Kenntnisnahme, Veröffentlichung,
> Vervielfältigung oder Wiedergabe des Inhalts dieser E-Mail unzulässig ist.
>  Bitte setzen Sie sich in diesem Fall mit dem Absender der E-Mail in
> Verbindung (br...@ba...).
>
>
>


- -- 

Regards
  Heiko Zuerker
  http://www.devil-linux.org

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iEYEARECAAYFAkRMxRgACgkQUcytMSbs+YXO8gCgqGSZNAJ2MqpwRMtksd0EkO84
ARcAn2sLVsEfShcJoATp6zLeQ2ezPp9e
=lWQF
-----END PGP SIGNATURE-----

Hello,

since a few weeks I try to build a custom DL build for my needs, which =
worked out fine the first time.

Now I'm about to go productive with my changes and wanted to upgrade my =
local lfssystem to reflect the last changes.

But since a few days there seems to be no way to update the local CVS =
from sf.net using:

cvs -d:pserver:ano...@cv...:/cvsroot/devil-linux login
 returns cvs [login aborted]: end of file from server (consult above =
messages if any)

investigations on sf.net turned out that the anonymous servers are down.

using ssh with my sf.net-account worked to connect the cvs but there are =
no rights to download :-(

are there any other ways to download the latests scripts for DL-release =
1.2 ???



Mit freundlichen Gr=FCssen=20

Bj=F6rn Rudner=20

____________________________________________=20
Bj=F6rn Rudner
Systemadministrator=20

baulogis GmbH
Zamdorfer Strasse 100
81677 M=FCnchen=20

Telefon	+49 (89) 930 839-16
Telefax	+49 1805 456 987-200 16=20
Mobil		+49 151 12 16 23 71=20
E-Mail 	br...@ba...=20
		http://www.baulogis.com/


_________________________________________________________________________=
___

Der Inhalt dieser E-Mail ist vertraulich und ausschlie=DFlich f=FCr den =
bezeichneten Adressaten (dev...@li...) =
bestimmt.
Wenn Sie nicht der vorgesehene Adressat dieser E-Mail oder dessen =
Vertreter sein sollten,
so beachten Sie bitte, dass jede Form der Kenntnisnahme, =
Ver=F6ffentlichung,=20
Vervielf=E4ltigung oder Wiedergabe des Inhalts dieser E-Mail =
unzul=E4ssig ist.
Bitte setzen Sie sich in diesem Fall mit dem Absender der E-Mail in =
Verbindung (br...@ba...).

> >> I was wondering if we should change the upgrade script and remove most
> >> of the confirmations. I was thinking to keep only the very first one and
> >> the dialog, where you can (de-)select the files.
> >
> > Getting carpal tunnel by pressing ENTER too much?  :-)
> 
> How did you know?
> 
> I don't think all the confirmations add any value.

It seems like some of those messages display useful information for
people who never run it before, and/or they let you scroll back in case
there were any errors.  I'd have to run it again to make sure, but there
may be some we can get rid of.

 - BS

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Mon, April 17, 2006 18:28, Bruce Smith wrote:
>> I was wondering if we should change the upgrade script and remove most
>> of the confirmations. I was thinking to keep only the very first one and
>> the dialog, where you can (de-)select the files.
>
> Getting carpal tunnel by pressing ENTER too much?  :-)

How did you know?

I don't think all the confirmations add any value.

- -- 

Regards
  Heiko Zuerker
  http://www.devil-linux.org

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iEYEARECAAYFAkRELuAACgkQUcytMSbs+YXiVgCeIwxt0UwaPkEZ7fCqPqLjDbRa
d+EAnipIqt7RiE2vkqxJgUvd5CNzpYUA
=epCC
-----END PGP SIGNATURE-----

> I was wondering if we should change the upgrade script and remove most of
> the confirmations.
> I was thinking to keep only the very first one and the dialog, where you
> can (de-)select the files.

Getting carpal tunnel by pressing ENTER too much?  :-)

 - BS

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hey,

I was wondering if we should change the upgrade script and remove most of
the confirmations.
I was thinking to keep only the very first one and the dialog, where you
can (de-)select the files.

- -- 

Regards
  Heiko Zuerker
  http://www.devil-linux.org

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iEYEARECAAYFAkRDi7YACgkQUcytMSbs+YUtoQCdFoCvvbPG3RVGJEBfIYH5Emnn
fzoAnRhBnJKIS6n2cEDH3KCwTmaRJu/E
=QrGa
-----END PGP SIGNATURE-----

Affects versions < 0.88.1 

 [ 1 ] CVE-2006-1614
        http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1614
  [ 2 ] CVE-2006-1615
        http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1615
  [ 3 ] CVE-2006-1630
        http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1630

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Mon, April 10, 2006 14:08, Friedrich Lobenstock wrote:
> Heiko Zuerker wrote on 10.04.2006 15:46 MET:
>
>> Hey,
>>
>>
>>
>> On Sat, April 8, 2006 17:48, Friedrich Lobenstock wrote:
>>
>>
>>>> Hi!
>>>>
>>>>
>>>>
>>>> I'm proposing a change to etc/init.d/ startscripts, namely adding a
>>>>  filesystem init routine to the start section which unpacks parts
>>>> of the /var/ filesystem if
>>>> the underlying filesystem which some daemon needs is currently
>>>> empty. This situation will happen when eg. LV 'log' gets mounted at
>>>> /var/log.
>>>>
>>>>
>>>> Attached is an example patch to etc/init.d/sysconfig.
>>>>
>>>>
>>>>
>>>> As you can see current existing files are not overwritten. In case
>>>> some files already exist but the check determines to do the
>>>> umpacking some error messages are genereated by tar because of the
>>>> already existing files.
>>>>
>>>> Only filtering stderr (2> /dev/null) does not seem logical to me as
>>>> I
>>>> wanted to show if something gets done, so I accepted the possible
>>>> case of distracting error messages. Those only say that a specific
>>>> file already existed and wasn't overwritten.
>>>>
>>>> I would add similar patches to those init script which I stumble
>>>> upon and am able to test.
>>
>>
>> It's probably the time of the day, but I ask anyway... ;-)
>>
>>
>> I can't see what this buys us, compared to the way we do thinks right
>> now.
>
> After you've booted a fresh DL create a LV named "var" in the VG
> "devil-linux",
> format it and then reboot the system. What do you see with "ls -al /var"
> after the reboot? No files if I'm correct, am I not?

Now that I'm finally awake, I can understand it. ;-)
Then I agree with the change.

- -- 

Regards
  Heiko Zuerker
  http://www.devil-linux.org

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iEYEARECAAYFAkQ6rp8ACgkQUcytMSbs+YXgqACeMHpgdw4iapj+zsUKHn4HisHo
tv4AnjiRSMLAOTOKi0C8oFMX5suIkvZt
=zc+L
-----END PGP SIGNATURE-----

Heiko Zuerker wrote on 10.04.2006 15:46 MET:
> Hey,
> 
> 
> On Sat, April 8, 2006 17:48, Friedrich Lobenstock wrote:
> 
>>>Hi!
>>>
>>>
>>>I'm proposing a change to etc/init.d/ startscripts, namely adding a
>>>filesystem init routine to the start section which unpacks parts of the
>>>/var/ filesystem if
>>>the underlying filesystem which some daemon needs is currently empty. This
>>> situation will happen when eg. LV 'log' gets mounted at /var/log.
>>>
>>>Attached is an example patch to etc/init.d/sysconfig.
>>>
>>>
>>>As you can see current existing files are not overwritten. In case some
>>>files already exist but the check determines to do the umpacking some
>>>error messages are genereated by tar because of the already existing
>>>files.
>>>
>>>Only filtering stderr (2> /dev/null) does not seem logical to me as I
>>>wanted to show if something gets done, so I accepted the possible case of
>>>distracting error messages. Those only say that a specific file already
>>>existed and wasn't overwritten.
>>>
>>>I would add similar patches to those init script which I stumble upon and
>>>am able to test.
> 
> 
> It's probably the time of the day, but I ask anyway... ;-)
> 
> I can't see what this buys us, compared to the way we do thinks right now.

After you've booted a fresh DL create a LV named "var" in the VG "devil-linux", 
format it and then reboot the system. What do you see with "ls -al /var" after 
the reboot? No files if I'm correct, am I not?

-- 
MfG / Regards
Friedrich Lobenstock
____________________________________________________________________
Friedrich Lobenstock                       Linux Services Lobenstock
URL: http://www.lsl.at/                         Email: fl...@fl...
____________________________________________________________________

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hey,


On Sat, April 8, 2006 17:48, Friedrich Lobenstock wrote:
> Hi!
>
>
> I'm proposing a change to etc/init.d/ startscripts, namely adding a
> filesystem init routine to the start section which unpacks parts of the
> /var/ filesystem if
> the underlying filesystem which some daemon needs is currently empty. This
>  situation will happen when eg. LV 'log' gets mounted at /var/log.
>
> Attached is an example patch to etc/init.d/sysconfig.
>
>
> As you can see current existing files are not overwritten. In case some
> files already exist but the check determines to do the umpacking some
> error messages are genereated by tar because of the already existing
> files.
>
> Only filtering stderr (2> /dev/null) does not seem logical to me as I
> wanted to show if something gets done, so I accepted the possible case of
> distracting error messages. Those only say that a specific file already
> existed and wasn't overwritten.
>
> I would add similar patches to those init script which I stumble upon and
> am able to test.

It's probably the time of the day, but I ask anyway... ;-)

I can't see what this buys us, compared to the way we do thinks right now.

- -- 

Regards
  Heiko Zuerker
  http://www.devil-linux.org

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iEYEARECAAYFAkQ6YckACgkQUcytMSbs+YXZewCeModZE029GWUtRF8hoEiFcbsq
R/kAn2ttGr1cvw7g6lQ9BQ+qdZA6bQ6f
=0YBr
-----END PGP SIGNATURE-----

Hi Heiko!

Heiko Zuerker wrote on 08.04.2006 03:17 MET:
> --- build.sh	7 Oct 2005 23:05:41 -0000	1.79.2.7
> +++ build.sh	8 Apr 2006 01:17:15 -0000	1.79.2.8
> @@ -126,29 +126,32 @@
>  
>  			mkdir -p $WORKDIR
>  			pushd $WORKDIR > /dev/null
> -
> -			for TAR in `ls $SRCDIR/*.tar.bz2`
> +			
> +			for DIR in $SRCDIR $SRCEXTRADIR
>  			do
> +			    for TAR in `ls $DIR/*.tar.bz2`

Guess you should add "2>/dev/null" to the ls, as to avoid the following bogus 
errors:

ls: /data/build/src-extra/*.tar.bz2: No such file or directory
ls: /data/build/src-extra/*.tar.gz: No such file or directory
ls: /data/build/src-extra/*.tgz: No such file or directory
ls: /data/build/src-extra/*.tar.Z: No such file or directory

-- 
MfG / Regards
Friedrich Lobenstock
____________________________________________________________________
Friedrich Lobenstock                       Linux Services Lobenstock
URL: http://www.lsl.at/                         Email: fl...@fl...
____________________________________________________________________

Hi Heiko!

Heiko Zuerker wrote on 08.04.2006 03:16 MET:
> --- CHANGES	7 Apr 2006 23:53:48 -0000	1.1025
> +++ CHANGES	8 Apr 2006 01:16:54 -0000	1.1026
> @@ -22,6 +22,8 @@
>  #
>  
>  1.3.2
> +- added new build directory src-extra for custom source files
> +  (will automatically be unpacked during "make unpack" and not deleted by update_src)
>  - fixed bug in mountfs introduced in DL release 1.1.3 (fl)
>  - updated cipe to v1.6.0
>  - added vmware modules (vmxnet & vmmemctl)

If I read that correctly that you removed the vmware modules from the offical 
source files (see below) than I suggest also removing the corresponding line 
(the last line shown above) from the CHANGES file.

> --- md5sum.lst	5 Apr 2006 19:19:22 -0000	1.274
> +++ md5sum.lst	8 Apr 2006 01:16:54 -0000	1.275
> @@ -471,8 +471,6 @@
>  af9d9e03038481fbf79ea3ac33f116f9  src/util-linux-2.12r.tar.bz2
>  821fda8f14d674346b87e3ef9cb96389  src/vim-6.3.tar.bz2
>  5f0c6060b33956fb16e11a15467dd394  src/vlan.1.9.tar.gz
> -4319169c9a35ea76657dc57ce751df66  src/vmmemctl.tar.bz2
> -0d98d57ceb5432ee520ddf54970eebe7  src/vmxnet.tar.bz2
>  dec2837d33fbc1f96f77014d01739126  src/vobcopy-0.5.13.tar.bz2
>  74936cbd8e8251deb1cd99c5fb18b6f8  src/vsftpd-2.0.3.tar.gz
>  6e676438028e80cd435ba581a7d41a17  src/vtun-2.5.tar.gz

-- 
MfG / Regards
Friedrich Lobenstock
____________________________________________________________________
Friedrich Lobenstock                       Linux Services Lobenstock
URL: http://www.lsl.at/                         Email: fl...@fl...
____________________________________________________________________

Hi!

I'm proposing a change to etc/init.d/ startscripts, namely adding a filesystem 
init routine to the start section which unpacks parts of the /var/ filesystem if 
the underlying filesystem which some daemon needs is currently empty. This 
situation will happen when eg. LV 'log' gets mounted at /var/log.

Attached is an example patch to etc/init.d/sysconfig.

As you can see current existing files are not overwritten. In case some files 
already exist but the check determines to do the umpacking some error messages 
are genereated by tar because of the already existing files.

Only filtering stderr (2> /dev/null) does not seem logical to me as I wanted to 
show if something gets done, so I accepted the possible case of distracting 
error messages. Those only say that a specific file already existed and wasn't 
overwritten.

I would add similar patches to those init script which I stumble upon and am 
able to test.

-- 
MfG / Regards
Friedrich Lobenstock
____________________________________________________________________
Friedrich Lobenstock                       Linux Services Lobenstock
URL: http://www.lsl.at/                         Email: fl...@fl...
____________________________________________________________________

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Sat, April 8, 2006 17:19, Friedrich Lobenstock wrote:
> Hi!
>
>
> Now that I've fixed a bug in /etc/init.d/mountfs which existed for
> straight two(2) years now (since DL release 1.1.3) I'm wanting to apply
> some changes to /etc/sysconfig/lvmtab. The bugfix makes it possible to
> mount LV's according to the order listed in lvmtab and NOT in the order of
> the LV's under /dev/devl-linux/.
>
> The changes are more or less the following:
> 1) add CVS headers so the lvmtab file can be more easily matched to CVS
> 2) polished description at start of file a little
> 3) changed tabs to spaces within the table of LV's
> 4) added more LV's which need correct ordering during mounting
>
>
> Does someone object to one of the changes, especially change #4 ?
> Otherwise I'll
> apply the changes to CVS tomorrow evening (MET, approx. 18 UTC).
>
> If you have some more candidate LV's for change #4 drop me a note and
> I'll add
> them to lvmtab.
>
> Please also take a look at the proposed mount options, I'd like to get
> some feedback an them too.

Looks good to me.

- -- 

Regards
  Heiko Zuerker
  http://www.devil-linux.org

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iEYEARECAAYFAkQ4O4QACgkQUcytMSbs+YU1UQCgpUJsRbOxsdvFbsPy7Vfu5t/6
CdoAoI7/cCSyLAH2Li1segdNwPoHW/eg
=nMPf
-----END PGP SIGNATURE-----

Hi!

Now that I've fixed a bug in /etc/init.d/mountfs which existed for straight 
two(2) years now (since DL release 1.1.3) I'm wanting to apply some changes to 
/etc/sysconfig/lvmtab. The bugfix makes it possible to mount LV's according to 
the order listed in lvmtab and NOT in the order of the LV's under /dev/devl-linux/.

The changes are more or less the following:
  1) add CVS headers so the lvmtab file can be more easily matched to CVS
  2) polished description at start of file a little
  3) changed tabs to spaces within the table of LV's
  4) added more LV's which need correct ordering during mounting

Does someone object to one of the changes, especially change #4 ? Otherwise I'll 
apply the changes to CVS tomorrow evening (MET, approx. 18 UTC).

If you have some more candidate LV's for change #4 drop me a note and I'll add 
them to lvmtab.

Please also take a look at the proposed mount options, I'd like to get some 
feedback an them too.

-- 
MfG / Regards
Friedrich Lobenstock
____________________________________________________________________
Friedrich Lobenstock                       Linux Services Lobenstock
URL: http://www.lsl.at/                         Email: fl...@fl...
____________________________________________________________________