From caleb at pld-linux.org  Sat May  1 13:58:35 2010
From: caleb at pld-linux.org (Caleb Maclennan)
Date: Sat, 1 May 2010 14:58:35 +0300
Subject: packages: flvtool2/flvtool2.spec, flvtool2/flvtool2-ruby19.patch 
	(NEW) - up...
In-Reply-To: <v2u5b3145a1005010457m243062d8sb3cbf4c7bb97a102@mail.gmail.com>
References: <packages_flvtool2_flvtool2.spec.1.10@pld-linux.org> 
	<packages_flvtool2_flvtool2_ruby19.patch.NONE@pld-linux.org> 
	<packages_flvtool2_flvtool2_ruby19.patch.1.1@pld-linux.org> 
	<v2u5b3145a1005010457m243062d8sb3cbf4c7bb97a102@mail.gmail.com>
Message-ID: <q2s5b3145a1005010458zaba1ae34t145b334c76a962c4@mail.gmail.com>

2010/5/1 caleb <caleb at pld-linux.org>:
> - patched setup script to run on ruby-1.9
> +Patch0: ? ? ? ? ? ? ? ?%{name}-ruby19.patch
> +%patch0 -p1

Some [widely bemoaned] changes to the way ruby handles string encoding
from 1.8 to 1.9 require changes in some scripts to run reliably. I
took a cue from several other patched pld packages and patched the
setup script for flvtools2 sot that it runs on ruby-1.9. The only
other way to make it run was to force the LANG to a non-utf8
selection, which didn't seem like the right option.

However this breaks the package build on ruby 1.8 systems. Is there an
acceptable way to mark a patch in the spec for inclusion only if the
host system is running a certain version of a package?

Caleb


From baggins at sith.mimuw.edu.pl  Sat May  1 16:13:26 2010
From: baggins at sith.mimuw.edu.pl (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Sat, 1 May 2010 16:13:26 +0200
Subject: packages: flvtool2/flvtool2.spec,
	flvtool2/flvtool2-ruby19.patch (NEW) - up...
In-Reply-To: <q2s5b3145a1005010458zaba1ae34t145b334c76a962c4@mail.gmail.com>
References: <packages_flvtool2_flvtool2.spec.1.10@pld-linux.org>
	<packages_flvtool2_flvtool2_ruby19.patch.NONE@pld-linux.org>
	<packages_flvtool2_flvtool2_ruby19.patch.1.1@pld-linux.org>
	<v2u5b3145a1005010457m243062d8sb3cbf4c7bb97a102@mail.gmail.com>
	<q2s5b3145a1005010458zaba1ae34t145b334c76a962c4@mail.gmail.com>
Message-ID: <20100501141326.GA24550@sith.mimuw.edu.pl>

On Sat, 01 May 2010, Caleb Maclennan wrote:

> 2010/5/1 caleb <caleb at pld-linux.org>:
> > - patched setup script to run on ruby-1.9
> > +Patch0: ? ? ? ? ? ? ? ?%{name}-ruby19.patch
> > +%patch0 -p1
> 
> Some [widely bemoaned] changes to the way ruby handles string encoding
> from 1.8 to 1.9 require changes in some scripts to run reliably. I
> took a cue from several other patched pld packages and patched the
> setup script for flvtools2 sot that it runs on ruby-1.9. The only
> other way to make it run was to force the LANG to a non-utf8
> selection, which didn't seem like the right option.
> 
> However this breaks the package build on ruby 1.8 systems. Is there an
> acceptable way to mark a patch in the spec for inclusion only if the
> host system is running a certain version of a package?

IMO the best way is to make a bcond, like this:

%bcond_with		ruby18		# build with ruby 1.8

%if %{with ruby18}
BuildRequires:		ruby >= 1.8
BuildConflicts:		ruby >= 1.9
%else
BuildRequires:		ruby >= 1.9
%endif

%{!?with_ruby18:%patch0 -p1}

this will give full control over build process.

-- 
Jan R?korajski            |  ALL SUSPECTS ARE GUILTY. PERIOD!
baggins<at>mimuw.edu.pl   |  OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY?
BOFH, MANIAC              |                   -- TROOPS by Kevin Rubio


From radek42 at gmail.com  Sat May  1 16:48:36 2010
From: radek42 at gmail.com (=?UTF-8?B?UmFkb3PFgmF3IFppZWxpxYRza2k=?=)
Date: Sat, 1 May 2010 09:48:36 -0500
Subject: packages: flvtool2/flvtool2.spec, flvtool2/flvtool2-ruby19.patch 
	(NEW) - up...
In-Reply-To: <q2s5b3145a1005010458zaba1ae34t145b334c76a962c4@mail.gmail.com>
References: <packages_flvtool2_flvtool2.spec.1.10@pld-linux.org>
	<packages_flvtool2_flvtool2_ruby19.patch.NONE@pld-linux.org>
	<packages_flvtool2_flvtool2_ruby19.patch.1.1@pld-linux.org>
	<v2u5b3145a1005010457m243062d8sb3cbf4c7bb97a102@mail.gmail.com>
	<q2s5b3145a1005010458zaba1ae34t145b334c76a962c4@mail.gmail.com>
Message-ID: <h2ha8dae1ea1005010748pbd0fc42cv233aa6c96f8f4118@mail.gmail.com>

On 1 May 2010 06:58, Caleb Maclennan <caleb at pld-linux.org> wrote:
> However this breaks the package build on ruby 1.8 systems. Is there an
> acceptable way to mark a patch in the spec for inclusion only if the
> host system is running a certain version of a package?

Writing portable patches is the preferred solution.

  if RUBY_VERSION < "1.9"
     ... force_encoding() ...
  end


From radek42 at gmail.com  Sat May  1 16:50:00 2010
From: radek42 at gmail.com (=?UTF-8?B?UmFkb3PFgmF3IFppZWxpxYRza2k=?=)
Date: Sat, 1 May 2010 09:50:00 -0500
Subject: packages: flvtool2/flvtool2.spec, flvtool2/flvtool2-ruby19.patch 
	(NEW) - up...
In-Reply-To: <h2ha8dae1ea1005010748pbd0fc42cv233aa6c96f8f4118@mail.gmail.com>
References: <packages_flvtool2_flvtool2.spec.1.10@pld-linux.org>
	<packages_flvtool2_flvtool2_ruby19.patch.NONE@pld-linux.org>
	<packages_flvtool2_flvtool2_ruby19.patch.1.1@pld-linux.org>
	<v2u5b3145a1005010457m243062d8sb3cbf4c7bb97a102@mail.gmail.com>
	<q2s5b3145a1005010458zaba1ae34t145b334c76a962c4@mail.gmail.com>
	<h2ha8dae1ea1005010748pbd0fc42cv233aa6c96f8f4118@mail.gmail.com>
Message-ID: <u2la8dae1ea1005010750t93e1b013pf29f3d65d76853cc@mail.gmail.com>

2010/5/1 Rados?aw Zieli?ski <radek42 at gmail.com>:
[...]
> ?if RUBY_VERSION < "1.9"

Oops: this should have been ">=", instead of "<".


From z at xatka.net  Sun May  2 17:01:49 2010
From: z at xatka.net (=?iso-8859-2?Q?Pawe=B3?= Zuzelski)
Date: Sun, 2 May 2010 17:01:49 +0200
Subject: packages: flvtool2/flvtool2.spec,
	flvtool2/flvtool2-ruby19.patch (NEW) - up...
In-Reply-To: <v2u5b3145a1005010457m243062d8sb3cbf4c7bb97a102@mail.gmail.com>
References: <packages_flvtool2_flvtool2.spec.1.10@pld-linux.org>
	<packages_flvtool2_flvtool2_ruby19.patch.NONE@pld-linux.org>
	<packages_flvtool2_flvtool2_ruby19.patch.1.1@pld-linux.org>
	<v2u5b3145a1005010457m243062d8sb3cbf4c7bb97a102@mail.gmail.com>
Message-ID: <20100502150149.GA4912@davabel.touk.pl>

On Sat, 01 May 2010, Caleb Maclennan wrote:

> 2010/5/1 caleb <caleb at pld-linux.org>:
> > - patched setup script to run on ruby-1.9
> > +Patch0: ? ? ? ? ? ? ? ?%{name}-ruby19.patch
> > +%patch0 -p1
> 
> Some [widely bemoaned] changes to the way ruby handles string encoding
> from 1.8 to 1.9 require changes in some scripts to run reliably. I
> took a cue from several other patched pld packages and patched the
> setup script for flvtools2 sot that it runs on ruby-1.9. The only
> other way to make it run was to force the LANG to a non-utf8
> selection, which didn't seem like the right option.
> 
> However this breaks the package build on ruby 1.8 systems. Is there an
> acceptable way to mark a patch in the spec for inclusion only if the
> host system is running a certain version of a package?

Please, don't reply to pld-cvs-commits list. Reply do pld-devel-en@
(or pld-devel-pl@).

Can anyone change the configuration of pld-cvs-commit to disallow
sending to that list?

-- 
Regards,
Pawe?


From z at xatka.net  Sun May  2 17:38:14 2010
From: z at xatka.net (=?iso-8859-2?Q?Pawe=B3?= Zuzelski)
Date: Sun, 2 May 2010 17:38:14 +0200
Subject: poldek -r broken again?
Message-ID: <20100502153814.GB4912@davabel.touk.pl>

or I'm missing something?

mkdir /th
poldek --update --upa
rpm --initdb -r /th
poldek -r /th
poldek> install geninitrd
(...)
error: open of /root/tmp/poldek-cache-root/http_ftp.sk.pld-linux.org.dists.th.PLD.i686.RPMS/ldconfig-2.11.1-5.i686.rpm failed: No such file or directory
error: open of /root/tmp/poldek-cache-root/http_ftp.sk.pld-linux.org.dists.th.PLD.i686.RPMS/filesystem-3.0-34.i686.rpm failed: No such file or directory
error: open of /root/tmp/poldek-cache-root/http_ftp.sk.pld-linux.org.dists.th.PLD.i686.RPMS/busybox-initrd-1.15.3-4.i686.rpm failed: No such file or directory
error: open of /root/tmp/poldek-cache-root/http_ftp.sk.pld-linux.org.dists.th.PLD.noarch.RPMS/rpm-whiteout-1.33-1.noarch.rpm failed: No such file or directory
error: open of /root/tmp/poldek-cache-root/http_ftp.sk.pld-linux.org.dists.th.PLD.noarch.RPMS/ca-certificates-20090814-6.noarch.rpm failed: No such file or directory
error: open of /root/tmp/poldek-cache-root/http_ftp.sk.pld-linux.org.dists.th.PLD.i686.RPMS/glibc-2.11.1-5.i686.rpm failed: No such file or directory
error: open of /root/tmp/poldek-cache-root/http_ftp.sk.pld-linux.org.dists.th.PLD.i686.RPMS/pdksh-5.2.14-56.i686.rpm failed: No such file or directory
(... a lot of similar errors)

BUT
poldek> install FHS
works.

-- 
Pawe?


From jajcus at jajcus.net  Sun May  2 18:03:10 2010
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Sun, 2 May 2010 18:03:10 +0200
Subject: poldek -r broken again?
In-Reply-To: <20100502153814.GB4912@davabel.touk.pl>
References: <20100502153814.GB4912@davabel.touk.pl>
Message-ID: <20100502160309.GA1114@lolek.nigdzie>

On Sun, May 02, 2010 at 05:38:14PM +0200, Pawe? Zuzelski wrote:
> or I'm missing something?
> 
> mkdir /th
> poldek --update --upa
> rpm --initdb -r /th

cd /

> poldek -r /th
> poldek> install geninitrd

Greets,
        Jacek


From sparky at pld-linux.org  Sun May  2 20:11:39 2010
From: sparky at pld-linux.org (Przemyslaw Iskra)
Date: Sun, 2 May 2010 20:11:39 +0200
Subject: poldek -r broken again?
In-Reply-To: <20100502153814.GB4912@davabel.touk.pl>
References: <20100502153814.GB4912@davabel.touk.pl>
Message-ID: <20100502181139.GA2210@pld-linux.org>

On Sun, May 02, 2010 at 05:38:14PM +0200, Pawe? Zuzelski wrote:
> or I'm missing something?
> 
> mkdir /th
> poldek --update --upa
> rpm --initdb -r /th
> poldek -r /th
> poldek> install geninitrd
> (...)
> error: open of /root/tmp/poldek-cache-root/http_ftp.sk.pld-linux.org.dists.th.PLD.i686.RPMS/ldconfig-2.11.1-5.i686.rpm failed: No such file or directory
> error: open of /root/tmp/poldek-cache-root/http_ftp.sk.pld-linux.org.dists.th.PLD.i686.RPMS/filesystem-3.0-34.i686.rpm failed: No such file or directory
^^^
This part exactly:

%if "%{pld_release}" != "ac"
%pretrans -p <lua>
-- this needs to be a dir
if posix.stat("/usr/include/X11", "type") == "link" then
	-- feel free to write in pure lua, but success on first install is not important.
	os.execute("umask 022; mv -f /usr/include/X11{,.rpmsave}; mkdir -m755 -p /usr/include/X11 && mv -f /usr/include/X11.rpmsave/*
/usr/include/X11")
end
%endif

Makes rpm lose track of current root directory. That is, it is unnable
to exit the chroot correctly before continuing instalation.

-- 
 ____  Sparky{PI] -- Przemyslaw _  ___  _  _  ........... LANG...Pl..Ca..Es..En
/____) ___  ___  _ _ || Iskra  |  | _ \| |  | : WWW........ppcrcd.pld-linux.org
\____\| -_)'___| ||^'||//\\// <   |  _/| |  | : JID......sparky<at>jabberes.org
(____/||   (_-_|_||  ||\\ ||   |_ |_|  |_| _| : Mail....sparky<at>pld-linux.org


From jajcus at jajcus.net  Sun May  2 20:16:22 2010
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Sun, 2 May 2010 20:16:22 +0200
Subject: poldek -r broken again?
In-Reply-To: <20100502181139.GA2210@pld-linux.org>
References: <20100502153814.GB4912@davabel.touk.pl>
	<20100502181139.GA2210@pld-linux.org>
Message-ID: <20100502181622.GB1114@lolek.nigdzie>

On Sun, May 02, 2010 at 08:11:39PM +0200, Przemyslaw Iskra wrote:
> %if "%{pld_release}" != "ac"
> %pretrans -p <lua>
> -- this needs to be a dir
> if posix.stat("/usr/include/X11", "type") == "link" then
> 	-- feel free to write in pure lua, but success on first install is not important.
> 	os.execute("umask 022; mv -f /usr/include/X11{,.rpmsave}; mkdir -m755 -p /usr/include/X11 && mv -f /usr/include/X11.rpmsave/*
> /usr/include/X11")
> end
> %endif
> 
> Makes rpm lose track of current root directory. That is, it is unnable
> to exit the chroot correctly before continuing instalation.

Oh, my investigation didn't go that far.  Anyway, starting poldek/rpm
with $PWD == '/' ('cd /' before running poldek) seems to be a working 
workaround.

Greets,
        Jacek


From n3npq at mac.com  Sun May  2 20:22:03 2010
From: n3npq at mac.com (Jeff Johnson)
Date: Sun, 02 May 2010 14:22:03 -0400
Subject: poldek -r broken again?
In-Reply-To: <20100502181139.GA2210@pld-linux.org>
References: <20100502153814.GB4912@davabel.touk.pl>
	<20100502181139.GA2210@pld-linux.org>
Message-ID: <668B3D2A-5768-4313-9CF1-179899A1C70B@mac.com>


On May 2, 2010, at 2:11 PM, Przemyslaw Iskra wrote:

> On Sun, May 02, 2010 at 05:38:14PM +0200, Pawe? Zuzelski wrote:
>> or I'm missing something?
>> 
>> mkdir /th
>> poldek --update --upa
>> rpm --initdb -r /th
>> poldek -r /th
>> poldek> install geninitrd
>> (...)
>> error: open of /root/tmp/poldek-cache-root/http_ftp.sk.pld-linux.org.dists.th.PLD.i686.RPMS/ldconfig-2.11.1-5.i686.rpm failed: No such file or directory
>> error: open of /root/tmp/poldek-cache-root/http_ftp.sk.pld-linux.org.dists.th.PLD.i686.RPMS/filesystem-3.0-34.i686.rpm failed: No such file or directory
> ^^^
> This part exactly:
> 
> %if "%{pld_release}" != "ac"
> %pretrans -p <lua>
> -- this needs to be a dir
> if posix.stat("/usr/include/X11", "type") == "link" then
> 	-- feel free to write in pure lua, but success on first install is not important.
> 	os.execute("umask 022; mv -f /usr/include/X11{,.rpmsave}; mkdir -m755 -p /usr/include/X11 && mv -f /usr/include/X11.rpmsave/*
> /usr/include/X11")
> end
> %endif
> 
> Makes rpm lose track of current root directory. That is, it is unnable
> to exit the chroot correctly before continuing instalation.
> 

Well the actual details aren't quite that simple even if the
flaw is (demonstrably and de facto) associated with using embedded
lua in %posttrans in the fhs package.

RPM for quite some years now (patch originally was from SuSE)
opens's the root directory, runs embedded lua, and then does fchdir(2)
to restore the root directory after lua is through doing whatever.

I haven't looked at rpm-4.5 for some years, but there's only a
single instance where fchdir(2) is used in RPM code so it should
not be hard to find.

73 de Jeff

From sparky at pld-linux.org  Sun May  2 20:45:01 2010
From: sparky at pld-linux.org (Przemyslaw Iskra)
Date: Sun, 2 May 2010 20:45:01 +0200
Subject: poldek -r broken again?
In-Reply-To: <668B3D2A-5768-4313-9CF1-179899A1C70B@mac.com>
References: <20100502153814.GB4912@davabel.touk.pl>
	<20100502181139.GA2210@pld-linux.org>
	<668B3D2A-5768-4313-9CF1-179899A1C70B@mac.com>
Message-ID: <20100502184501.GA4640@pld-linux.org>

On Sun, May 02, 2010 at 02:22:03PM -0400, Jeff Johnson wrote:
> 
> On May 2, 2010, at 2:11 PM, Przemyslaw Iskra wrote:
> 
> > 
> > Makes rpm lose track of current root directory. That is, it is unnable
> > to exit the chroot correctly before continuing instalation.
> > 
> 
> Well the actual details aren't quite that simple even if the
> flaw is (demonstrably and de facto) associated with using embedded
> lua in %posttrans in the fhs package.
> 
> RPM for quite some years now (patch originally was from SuSE)
> opens's the root directory, runs embedded lua, and then does fchdir(2)
> to restore the root directory after lua is through doing whatever.
> 
> I haven't looked at rpm-4.5 for some years, but there's only a
> single instance where fchdir(2) is used in RPM code so it should
> not be hard to find.

If anyone is going to fix that, here goes strace with my comments:

I'm in /tmp directory and I'm going to install something in /tmp/chroot:
[sparky at quad /tmp]$ rpm --root=/tmp/chroot/ -Uhv rpm/*

[...]

getcwd("/tmp", 4096)                    = 5

  -- so we are in /tmp yet

[...] no chdir or anything in those calls

open(".", O_RDONLY)                     = 7
  -- opens dir handle to /tmp, it should chdir("/") before making this
     call !

chroot("/tmp/chroot/")                  = 0
chdir("/")                              = 0
  -- entered chroot correctly

lstat("/usr/include/X11", 0x7fffc481e990) = -1 ENOENT (No such file or directory)
  -- executes lua

fchdir(7)                               = 0
  -- changes dir to saved dir handle (prepares to exit chroot)

chroot(".")                             = 0
  -- chroots back to /tmp !
     This way /tmp becomes new root.

close(7)                                = 0



To make it work it should open current directory (/tmp),
chdir to / and open that directory. Then enter chroot.

To exit chroot it should fchdir to old /, chroot there, and
fchdir to old working directory.

-- 
 ____  Sparky{PI] -- Przemyslaw _  ___  _  _  ........... LANG...Pl..Ca..Es..En
/____) ___  ___  _ _ || Iskra  |  | _ \| |  | : WWW........ppcrcd.pld-linux.org
\____\| -_)'___| ||^'||//\\// <   |  _/| |  | : JID......sparky<at>jabberes.org
(____/||   (_-_|_||  ||\\ ||   |_ |_|  |_| _| : Mail....sparky<at>pld-linux.org


From n3npq at mac.com  Sun May  2 20:57:39 2010
From: n3npq at mac.com (Jeff Johnson)
Date: Sun, 02 May 2010 14:57:39 -0400
Subject: poldek -r broken again?
In-Reply-To: <20100502184501.GA4640@pld-linux.org>
References: <20100502153814.GB4912@davabel.touk.pl>
	<20100502181139.GA2210@pld-linux.org>
	<668B3D2A-5768-4313-9CF1-179899A1C70B@mac.com>
	<20100502184501.GA4640@pld-linux.org>
Message-ID: <286CF004-CDD6-43AD-B77E-46C2FE79948C@mac.com>


On May 2, 2010, at 2:45 PM, Przemyslaw Iskra wrote:

> On Sun, May 02, 2010 at 02:22:03PM -0400, Jeff Johnson wrote:
>> 
>> On May 2, 2010, at 2:11 PM, Przemyslaw Iskra wrote:
>> 
>>> 
>>> Makes rpm lose track of current root directory. That is, it is unnable
>>> to exit the chroot correctly before continuing instalation.
>>> 
>> 
>> Well the actual details aren't quite that simple even if the
>> flaw is (demonstrably and de facto) associated with using embedded
>> lua in %posttrans in the fhs package.
>> 
>> RPM for quite some years now (patch originally was from SuSE)
>> opens's the root directory, runs embedded lua, and then does fchdir(2)
>> to restore the root directory after lua is through doing whatever.
>> 
>> I haven't looked at rpm-4.5 for some years, but there's only a
>> single instance where fchdir(2) is used in RPM code so it should
>> not be hard to find.
> 
> If anyone is going to fix that, here goes strace with my comments:
> 

I'd fix if I thought there was a flaw. So far I don't see the flaw.
Please note that I'm not arguing or disagreeing, just I don't see the flaw.


> I'm in /tmp directory and I'm going to install something in /tmp/chroot:
> [sparky at quad /tmp]$ rpm --root=/tmp/chroot/ -Uhv rpm/*
> 
> [...]
> 
> getcwd("/tmp", 4096)                    = 5
> 

This is the current working directory for your invocation.

>  -- so we are in /tmp yet
> 
> [...] no chdir or anything in those calls
> 

Yes. RPM attempts to _NEVER_ do chdir(2) (but it gets
trickier running opaque embedded lua scripts because
the scripts can change RPM's current working directory.

> open(".", O_RDONLY)                     = 7
>  -- opens dir handle to /tmp, it should chdir("/") before making this
>     call !
> 

Why should chdir("/") be done. Its the current working directory
that RPM is trying to preserve.

> chroot("/tmp/chroot/")                  = 0
> chdir("/")                              = 0
>  -- entered chroot correctly
> 

OK.

> lstat("/usr/include/X11", 0x7fffc481e990) = -1 ENOENT (No such file or directory)
>  -- executes lua
> 
> fchdir(7)                               = 0
>  -- changes dir to saved dir handle (prepares to exit chroot)
> 
> chroot(".")                             = 0
>  -- chroots back to /tmp !
>     This way /tmp becomes new root.
> 

... which re-establishes the cwd before embedded lua was run.

> close(7)                                = 0
> 
> 
> 
> To make it work it should open current directory (/tmp),
> chdir to / and open that directory. Then enter chroot.
> 

Perfectly willing to do that if you explain your expectations
more completely.

My guess is that you want a deterministic chdir("/") when running
opaque embedded lua scripts. You certainly can do chdir("/") within
the lua script if you wish.

The disagreement seems largely to be what you expect RPM to do vs. what
should be done in embedded scriptlets. And there's truly so few embedded
scripts in *.rpm that noone (certainly not me) has ever tried
to pin down the execution environment precisely.

> To exit chroot it should fchdir to old /, chroot there, and
> fchdir to old working directory.
> 

And your old working directory is (in fact) /tmp which was restored by fchdir(2).

73 de jeff


From sparky at pld-linux.org  Sun May  2 21:14:36 2010
From: sparky at pld-linux.org (Przemyslaw Iskra)
Date: Sun, 2 May 2010 21:14:36 +0200
Subject: poldek -r broken again?
In-Reply-To: <286CF004-CDD6-43AD-B77E-46C2FE79948C@mac.com>
References: <20100502153814.GB4912@davabel.touk.pl>
	<20100502181139.GA2210@pld-linux.org>
	<668B3D2A-5768-4313-9CF1-179899A1C70B@mac.com>
	<20100502184501.GA4640@pld-linux.org>
	<286CF004-CDD6-43AD-B77E-46C2FE79948C@mac.com>
Message-ID: <20100502191436.GA10776@pld-linux.org>

On Sun, May 02, 2010 at 02:57:39PM -0400, Jeff Johnson wrote:
> 
> > chroot(".")                             = 0
> >  -- chroots back to /tmp !
> >     This way /tmp becomes new root.
> > 
> 
> ... which re-establishes the cwd before embedded lua was run.

It also establishes /tmp as new /, so now when you use path:
/tmp/rpm/something it points to /tmp/tmp/rpm/something in real root.


Please, google for "breaking out of chroot", some of those tutorials
are nicely explained.

> My guess is that you want a deterministic chdir("/") when running
> opaque embedded lua scripts. You certainly can do chdir("/") within
> the lua script if you wish.
> 
> The disagreement seems largely to be what you expect RPM to do vs. what
> should be done in embedded scriptlets. And there's truly so few embedded
> scripts in *.rpm that noone (certainly not me) has ever tried
> to pin down the execution environment precisely.

I have no idea why it doesn't work in this case, but works in all
others. Are %post and %pre scripts run as separate processes ?

> > To exit chroot it should fchdir to old /, chroot there, and
> > fchdir to old working directory.
> > 
> 
> And your old working directory is (in fact) /tmp which was restored by fchdir(2).

/tmp also becomes new /, which brakes full paths (ones starting with /).


-- 
 ____  Sparky{PI] -- Przemyslaw _  ___  _  _  ........... LANG...Pl..Ca..Es..En
/____) ___  ___  _ _ || Iskra  |  | _ \| |  | : WWW........ppcrcd.pld-linux.org
\____\| -_)'___| ||^'||//\\// <   |  _/| |  | : JID......sparky<at>jabberes.org
(____/||   (_-_|_||  ||\\ ||   |_ |_|  |_| _| : Mail....sparky<at>pld-linux.org


From n3npq at mac.com  Sun May  2 21:23:32 2010
From: n3npq at mac.com (Jeff Johnson)
Date: Sun, 02 May 2010 15:23:32 -0400
Subject: poldek -r broken again?
In-Reply-To: <20100502191436.GA10776@pld-linux.org>
References: <20100502153814.GB4912@davabel.touk.pl>
	<20100502181139.GA2210@pld-linux.org>
	<668B3D2A-5768-4313-9CF1-179899A1C70B@mac.com>
	<20100502184501.GA4640@pld-linux.org>
	<286CF004-CDD6-43AD-B77E-46C2FE79948C@mac.com>
	<20100502191436.GA10776@pld-linux.org>
Message-ID: <B0346DE5-1288-446B-8C63-B0E7C2F62483@mac.com>


On May 2, 2010, at 3:14 PM, Przemyslaw Iskra wrote:

> On Sun, May 02, 2010 at 02:57:39PM -0400, Jeff Johnson wrote:
>> 
>>> chroot(".")                             = 0
>>> -- chroots back to /tmp !
>>>    This way /tmp becomes new root.
>>> 
>> 
>> ... which re-establishes the cwd before embedded lua was run.
> 
> It also establishes /tmp as new /, so now when you use path:
> /tmp/rpm/something it points to /tmp/tmp/rpm/something in real root.
> 

Send along a patch if you want a fix. The code is in lib/psm.c,
and the patch is likely less than 5 lines (which is >2 orders of magnitude
fewer lines than have already been written about Glen's %pretrans script)

73 de Jeff



From caleb at pld-linux.org  Mon May  3 20:05:41 2010
From: caleb at pld-linux.org (Caleb Maclennan)
Date: Mon, 3 May 2010 21:05:41 +0300
Subject: Old kernel without udev
Message-ID: <t2m5b3145a1005031105z8b1c14d3u7106121385cac32@mail.gmail.com>

Does anybody have any input on keeping a TH system up to date while
being forced to run an old kernel (2.6.16) not compatible with current
udev packages?

Is it possible these days to not have udev packages installed at all?

Or should I work on setting up a custom udev package with an an older
version: something from the same generation as the kernel?

Thanks and regards,
Caleb


From patrys at pld-linux.org  Mon May  3 21:55:16 2010
From: patrys at pld-linux.org (Patryk Zawadzki)
Date: Mon, 3 May 2010 21:55:16 +0200
Subject: Old kernel without udev
In-Reply-To: <t2m5b3145a1005031105z8b1c14d3u7106121385cac32@mail.gmail.com>
References: <t2m5b3145a1005031105z8b1c14d3u7106121385cac32@mail.gmail.com>
Message-ID: <l2r89b6ba3a1005031255y3c3b6c1cybae3bf0011b7c697@mail.gmail.com>

On Mon, May 3, 2010 at 8:05 PM, Caleb Maclennan <caleb at pld-linux.org> wrote:
> Does anybody have any input on keeping a TH system up to date while
> being forced to run an old kernel (2.6.16) not compatible with current
> udev packages?
>
> Is it possible these days to not have udev packages installed at all?
>
> Or should I work on setting up a custom udev package with an an older
> version: something from the same generation as the kernel?

Isn't udev-compat enough? If not, maybe create another compat package?

-- 
Patryk Zawadzki


From hawk at limanowa.net  Mon May  3 22:14:25 2010
From: hawk at limanowa.net (Marcin Krol)
Date: Mon, 03 May 2010 22:14:25 +0200
Subject: Old kernel without udev
In-Reply-To: <t2m5b3145a1005031105z8b1c14d3u7106121385cac32@mail.gmail.com>
References: <t2m5b3145a1005031105z8b1c14d3u7106121385cac32@mail.gmail.com>
Message-ID: <4BDF2EA1.30306@limanowa.net>

> Is it possible these days to not have udev packages installed at all?

>From what I know... no. But I may be totally wrong :-)

I had bunch of machines running with static dev. They were fine with
kernel 2.6.27.x, but stopped working properly with kernel 2.6.32.x. One
was unable to initialize network card saying something about corrupted
firmware in dmesg. Second was unable to use USB drivers, they loaded
fine but not a single USB device was working properly, keyboard and
mouse included. Third was hanging on activating network card, nothing in
logs. Fourth said that RAID controller won't work because firmware is
too old... and few others things like that.

They all started to work properly after replacing static dev with udev.

So its a two sided blade - you won't be able to run kernel older than
2.6.30.x with recent udev, you won't be able to run recent udev as well
if kernel is too old. You must either keep both things old or both
things up to date.

Bascially I'm very disappointed by recent kernels and the way they go,
but thats not proper place to discuss it :-)

M.


From jajcus at jajcus.net  Tue May  4 11:17:41 2010
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Tue, 4 May 2010 11:17:41 +0200
Subject: Native upstart scripts
Message-ID: <20100504091741.GA31617@jajo.eggsoft>

Hello,

In PLD Th, we have upstart as the /sbin/init daemon for some time, but
it is only used to start the old 'SysVinit' scripts from
/etc/rc.d/init.d. To make full use of Upstart features, like process
supervising, parallel start, etc. we should find a way to include
Upstart support in our packages. Though, we should not replace the
current, working solution.

I think Upstart support should be implemented as an option, coexisting
with current solution, so the administrator may choose what he prefers
and even use init.d for some services and upstart for other.

My proposition:

- packages will provide upstart configuration files in /etc/rc.d/upstart
- those could be linked or copied to /etc/init/subsys when needed
  - chkconfig would link/unlink the files when requested (global
    configuration option and command line option to prefer upstart)
  - user could copy them manually and modify them if needed
- rc-scripts won't start/stop services via /etc/rc.d/init.d scripts when
  /etc/init/subsys/$name exists
- 'service' script would use 'initctl' instead of /etc/rc.d/init.d 
  when /etc/init/subsys/$name exists
- scripts in /etc/rc.d/init.d would emit 'started' and 'stopped' 
  events when necessary, so upstart services can rely on that

What do you think? Should I try to prepare a proof-of-concept
implementation?

P.S. Does anybody read those 'long' posts I send to pld-devel-en? ;)


From patrys at pld-linux.org  Tue May  4 12:04:39 2010
From: patrys at pld-linux.org (Patryk Zawadzki)
Date: Tue, 4 May 2010 12:04:39 +0200
Subject: Native upstart scripts
In-Reply-To: <20100504091741.GA31617@jajo.eggsoft>
References: <20100504091741.GA31617@jajo.eggsoft>
Message-ID: <j2k89b6ba3a1005040304v9f36b62fj2742621bc2b19c23@mail.gmail.com>

On Tue, May 4, 2010 at 11:17 AM, Jacek Konieczny <jajcus at jajcus.net> wrote:
> Hello,
>
> In PLD Th, we have upstart as the /sbin/init daemon for some time, but
> it is only used to start the old 'SysVinit' scripts from
> /etc/rc.d/init.d. To make full use of Upstart features, like process
> supervising, parallel start, etc. we should find a way to include
> Upstart support in our packages. Though, we should not replace the
> current, working solution.

+1

> I think Upstart support should be implemented as an option, coexisting
> with current solution, so the administrator may choose what he prefers
> and even use init.d for some services and upstart for other.

I was hoping for eventually dropping rc scripts for some services and
moving them completely to upstart. I see why that might sound scary
and am ok with having two solutions.

> My proposition:
>
> - packages will provide upstart configuration files in /etc/rc.d/upstart
> - those could be linked or copied to /etc/init/subsys when needed
> ?- chkconfig would link/unlink the files when requested (global
> ? ?configuration option and command line option to prefer upstart)
> ?- user could copy them manually and modify them if needed
> - rc-scripts won't start/stop services via /etc/rc.d/init.d scripts when
> ?/etc/init/subsys/$name exists
> - 'service' script would use 'initctl' instead of /etc/rc.d/init.d
> ?when /etc/init/subsys/$name exists
> - scripts in /etc/rc.d/init.d would emit 'started' and 'stopped'
> ?events when necessary, so upstart services can rely on that

I'd opt for having 2 separate -init subpackages, one with the current
rc.d contents and one with an upstart job description and a simple
rc.d wrapper that runs "start $foo", "stop $foo" etc.

As for emitting signals, we should add these as required by
dependencies. I see no gain from adding them to every rc.d script.

> What do you think? Should I try to prepare a proof-of-concept
> implementation?

Ladies and gentlemen, we have a volunteer :)

-- 
Patryk Zawadzki


From caleb at pld-linux.org  Tue May  4 12:22:26 2010
From: caleb at pld-linux.org (Caleb Maclennan)
Date: Tue, 4 May 2010 13:22:26 +0300
Subject: Native upstart scripts
In-Reply-To: <20100504091741.GA31617@jajo.eggsoft>
References: <20100504091741.GA31617@jajo.eggsoft>
Message-ID: <j2k5b3145a1005040322i5f9bdebdj124c52fa25c7923@mail.gmail.com>

2010/5/4 Jacek Konieczny <jajcus at jajcus.net>:
> I think Upstart support should be implemented as an option, coexisting
> with current solution, so the administrator may choose what he prefers
> and even use init.d for some services and upstart for other.

+1

> ?- chkconfig would link/unlink the files when requested (global
> ? ?configuration option and command line option to prefer upstart)

Your implementation sounds reasonable. I have several systems I will
be interested in trying this out on.

> P.S. Does anybody read those 'long' posts I send to pld-devel-en? ;)

Yes. Particularly as a new developer seeing verbose discussion of
various decisions is quite helpful.

Caleb


From glen at delfi.ee  Tue May  4 12:10:35 2010
From: glen at delfi.ee (Elan =?iso-8859-1?q?Ruusam=E4e?=)
Date: Tue, 4 May 2010 13:10:35 +0300
Subject: Native upstart scripts
In-Reply-To: <20100504091741.GA31617@jajo.eggsoft>
References: <20100504091741.GA31617@jajo.eggsoft>
Message-ID: <201005041310.36097.glen@delfi.ee>

On Tuesday 04 May 2010 12:17:41 Jacek Konieczny wrote:
> What do you think? Should I try to prepare a proof-of-concept
> implementation?

i describe ubuntu like implementation that i had in first mind to do:

1. some packages have been migrated to upstart, 
having /etc/init/<service>.conf file
2. those packages initscript is symlinked: 
to /etc/rc.d/init.d<service> -> /lib/init/upstart-job
3. upstart-job suggests to use 'service <service> to start if invoked directly 
via /etc/rc.d/init.d
4. /sbin/service, sees if invoked service jas /etc/init/<service>.conf and 
invokes via upstart, otherwise fallbacks to sysvninit mode

upstart-job is included in upstart package, /sbin/service diff in attachment.

however this assumes you already have upstart in target, i.e you preserve 
invoking old way, but require upstart being present.

and this does not handle chkconfig integration due the symlink, i.e booting 
without upstart sequence is unknown.

i've also packaged two packages from ubuntu to pld: mountall and ureadahead

> P.S. Does anybody read those 'long' posts I send to pld-devel-en? ;)

i would had answered bacula one, if i had chance to test bacula 5.0

-- 
glen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: service.patch
Type: text/x-diff
Size: 673 bytes
Desc: not available
URL: </mailman/pipermail/pld-devel-en/attachments/20100504/b4cdcf96/attachment.bin>

From jajcus at jajcus.net  Tue May  4 12:34:13 2010
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Tue, 4 May 2010 12:34:13 +0200
Subject: Native upstart scripts
In-Reply-To: <j2k89b6ba3a1005040304v9f36b62fj2742621bc2b19c23@mail.gmail.com>
References: <20100504091741.GA31617@jajo.eggsoft>
	<j2k89b6ba3a1005040304v9f36b62fj2742621bc2b19c23@mail.gmail.com>
Message-ID: <20100504103413.GB31617@jajo.eggsoft>

On Tue, May 04, 2010 at 12:04:39PM +0200, Patryk Zawadzki wrote:
> > I think Upstart support should be implemented as an option, coexisting
> > with current solution, so the administrator may choose what he prefers
> > and even use init.d for some services and upstart for other.
> 
> I was hoping for eventually dropping rc scripts for some services and
> moving them completely to upstart. I see why that might sound scary
> and am ok with having two solutions.

I think we can drop rc-scripts some day, but first the alternative must
be well-tested. Having the two alternatives co-exist every one may gradually 
migrate to upstart in his own pace.

And dropping /etc/rc.d/init.d/* in Th will make another difference to
Ti? I guess we don't wont PLD split even more.

Another thing to consider is LSB compatibility? some services expect
/etc/init.d scripts doing their stuff. 

Maybe we could make /etc/init.d a directory with symlinks to
/etc/rc.d/init.d or the upstart wrapper, depending on what is used to
handle the service?

> I'd opt for having 2 separate -init subpackages, one with the current
> rc.d contents and one with an upstart job description and a simple
> rc.d wrapper that runs "start $foo", "stop $foo" etc.

Extra two subpackages for every daemon? I would prefer to avoid that.

> As for emitting signals, we should add these as required by
> dependencies. I see no gain from adding them to every rc.d script.

Hmm. That makes sense. Some event will be implemented in rc-scripts
(line 'network started').

On the other hand, if we make rc-scripts function which does 
 touch /var/lock/subsys/$name; initctl emit subsys/$name started
and another to:
 rm -f /var/lock/subsys/$name; initctl emit subsys/$name stopped

Then integrating the signals will be very easy.

Greets,
        Jacek


From jajcus at jajcus.net  Tue May  4 12:53:40 2010
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Tue, 4 May 2010 12:53:40 +0200
Subject: Native upstart scripts
In-Reply-To: <j2k89b6ba3a1005040304v9f36b62fj2742621bc2b19c23@mail.gmail.com>
References: <20100504091741.GA31617@jajo.eggsoft>
	<j2k89b6ba3a1005040304v9f36b62fj2742621bc2b19c23@mail.gmail.com>
Message-ID: <20100504105340.GC31617@jajo.eggsoft>

On Tue, May 04, 2010 at 12:04:39PM +0200, Patryk Zawadzki wrote:
> > - scripts in /etc/rc.d/init.d would emit 'started' and 'stopped'
> > ?events when necessary, so upstart services can rely on that
> 
> I'd opt for having 2 separate -init subpackages, one with the current
> rc.d contents and one with an upstart job description and a simple
> rc.d wrapper that runs "start $foo", "stop $foo" etc.

There is one more thing why I would prefer to keep both old-style init.d
script and the new upstart configuration together: we often have
something more than 'start' 'stop' and 'status' implemented in the init
scripts. Some of these actions would have to be copied to upstart
script somehow (initialization before first run), other probably cannot
be handled by upstart means.

sshd init script builds host keys the first time it is started. This
functionality is available also via '/etc/rc.d/init.d/sshd init' and
would have to be copied to the upstart configuration to and maintained
in the two places.

As starting and stopping of services is quite different in LSB init
scripts and upstart and reusing code does not make sens, in other cases,
like 'init' the code may be reused and upstart script could just call
'/etc/rc.d/init.d/sshd init'. 

Also, there are things like '/etc/rc.d/init.d/lighttpd configtest' which
are not part of normal job control and thus not applicable to upstart
config, but still useful.

Greets,
        Jacek


From blues at pld-linux.org  Tue May  4 16:02:07 2010
From: blues at pld-linux.org (Pawel Golaszewski)
Date: Tue, 4 May 2010 16:02:07 +0200 (CEST)
Subject: Native upstart scripts
In-Reply-To: <20100504091741.GA31617@jajo.eggsoft>
References: <20100504091741.GA31617@jajo.eggsoft>
Message-ID: <alpine.LNX.2.00.1005041601230.19522@fgnss.gnfx.tqn.cy>

On Tue, 4 May 2010, Jacek Konieczny wrote:
[...]
> P.S. Does anybody read those 'long' posts I send to pld-devel-en? ;)

yep.
only the last part ;)

-- 
pozdr.  Pawe? Go?aszewski          jid:blues<at>jabber<dot>gda<dot>pl
--------------------------------------------------------------------------
If you think of MS-DOS as mono, and Windows as stereo, then Linux is Dolby
Pro-Logic Surround Sound with Bass Boost and all the music is free.

From blues at pld-linux.org  Tue May  4 16:04:49 2010
From: blues at pld-linux.org (Pawel Golaszewski)
Date: Tue, 4 May 2010 16:04:49 +0200 (CEST)
Subject: Native upstart scripts
In-Reply-To: <j2k89b6ba3a1005040304v9f36b62fj2742621bc2b19c23@mail.gmail.com>
References: <20100504091741.GA31617@jajo.eggsoft>
	<j2k89b6ba3a1005040304v9f36b62fj2742621bc2b19c23@mail.gmail.com>
Message-ID: <alpine.LNX.2.00.1005041602370.19522@fgnss.gnfx.tqn.cy>

On Tue, 4 May 2010, Patryk Zawadzki wrote:
> > I think Upstart support should be implemented as an option, coexisting 
> > with current solution, so the administrator may choose what he prefers 
> > and even use init.d for some services and upstart for other.
> I was hoping for eventually dropping rc scripts for some services and
> moving them completely to upstart. I see why that might sound scary
> and am ok with having two solutions.

-ENOWAY !
Don't remove working sollution.

It can be done for new services, but not for existing-ones.

> I'd opt for having 2 separate -init subpackages, one with the current
> rc.d contents and one with an upstart job description and a simple
> rc.d wrapper that runs "start $foo", "stop $foo" etc.

I wanted to say something like that.

> > What do you think? Should I try to prepare a proof-of-concept 
> > implementation?
> Ladies and gentlemen, we have a volunteer :)

hip-hip, hura!!! ;)

-- 
pozdr.  Pawe? Go?aszewski          jid:blues<at>jabber<dot>gda<dot>pl
--------------------------------------------------------------------------
If you think of MS-DOS as mono, and Windows as stereo, then Linux is Dolby
Pro-Logic Surround Sound with Bass Boost and all the music is free.

From blues at pld-linux.org  Tue May  4 16:08:07 2010
From: blues at pld-linux.org (Pawel Golaszewski)
Date: Tue, 4 May 2010 16:08:07 +0200 (CEST)
Subject: Native upstart scripts
In-Reply-To: <20100504103413.GB31617@jajo.eggsoft>
References: <20100504091741.GA31617@jajo.eggsoft>
	<j2k89b6ba3a1005040304v9f36b62fj2742621bc2b19c23@mail.gmail.com>
	<20100504103413.GB31617@jajo.eggsoft>
Message-ID: <alpine.LNX.2.00.1005041605340.19522@fgnss.gnfx.tqn.cy>

On Tue, 4 May 2010, Jacek Konieczny wrote:
> Maybe we could make /etc/init.d a directory with symlinks to 
> /etc/rc.d/init.d or the upstart wrapper, depending on what is used to 
> handle the service?

see how ubuntu made this.
Every service is in that directory, some are links.
I can see how does it looks like at home, later.

> > I'd opt for having 2 separate -init subpackages, one with the current
> > rc.d contents and one with an upstart job description and a simple
> > rc.d wrapper that runs "start $foo", "stop $foo" etc.
> Extra two subpackages for every daemon? I would prefer to avoid that.

but you can make ignores in poldek with that and make it easy to use.

-- 
pozdr.  Pawe? Go?aszewski          jid:blues<at>jabber<dot>gda<dot>pl
--------------------------------------------------------------------------
If you think of MS-DOS as mono, and Windows as stereo, then Linux is Dolby
Pro-Logic Surround Sound with Bass Boost and all the music is free.

From glen at delfi.ee  Tue May  4 18:40:43 2010
From: glen at delfi.ee (Elan =?iso-8859-1?q?Ruusam=E4e?=)
Date: Tue, 4 May 2010 19:40:43 +0300
Subject: Native upstart scripts
In-Reply-To: <20100504091741.GA31617@jajo.eggsoft>
References: <20100504091741.GA31617@jajo.eggsoft>
Message-ID: <201005041940.43253.glen@delfi.ee>

On Tuesday 04 May 2010 12:17:41 Jacek Konieczny wrote:
> My proposition:
> - packages will provide upstart configuration files in /etc/rc.d/upstart
> - those could be linked or copied to /etc/init/subsys when needed
> ? - chkconfig would link/unlink the files when requested (global
> ? ? configuration option and command line option to prefer upstart)
> ? - user could copy them manually and modify them if needed

i don't like the idea that the links are managed via some script, i'd like 
easily to boot to upstart-mode or sysvinit-mode with a kernel commandline, or 
something in /etc/sysconfig/system the both solutions should be available and 
configured at the same time.

also i'd not invent new paths, but use /etc/init for upstart scripts.

> - rc-scripts won't start/stop services via /etc/rc.d/init.d scripts when
> ? /etc/init/subsys/$name exists
> - 'service' script would use 'initctl' instead of /etc/rc.d/init.d
> ? when /etc/init/subsys/$name exists
> - scripts in /etc/rc.d/init.d would emit 'started' and 'stopped'
> ? events when necessary, so upstart services can rely on that

otherwise matches quite much with my vision...

-- 
glen


From jajcus at jajcus.net  Tue May  4 19:51:49 2010
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Tue, 4 May 2010 19:51:49 +0200
Subject: Native upstart scripts
In-Reply-To: <201005041940.43253.glen@delfi.ee>
References: <20100504091741.GA31617@jajo.eggsoft>
	<201005041940.43253.glen@delfi.ee>
Message-ID: <20100504175149.GA4029@lolek.nigdzie>

On Tue, May 04, 2010 at 07:40:43PM +0300, Elan Ruusam?e wrote:
> On Tuesday 04 May 2010 12:17:41 Jacek Konieczny wrote:
> > My proposition:
> > - packages will provide upstart configuration files in /etc/rc.d/upstart
> > - those could be linked or copied to /etc/init/subsys when needed
> > ? - chkconfig would link/unlink the files when requested (global
> > ? ? configuration option and command line option to prefer upstart)
> > ? - user could copy them manually and modify them if needed
> 
> i don't like the idea that the links are managed via some script, i'd like 
> easily to boot to upstart-mode or sysvinit-mode with a kernel commandline, or 
> something in /etc/sysconfig/system the both solutions should be available and 
> configured at the same time.

I'll take this into account. Though keeping both configured could cause
mistakes like starting a service again the different way. I guess this
can be solved somehow anyway
 
> also i'd not invent new paths, but use /etc/init for upstart scripts.

Recent upstart allows hierarchical names. I thought a separate namespace
(subsys/* or rc/*) for the rc-scripts equivalents would be a good idea.
Now I think it will be probably better to use subdirs for local stuff
(/etc/init/local -> local/* jobs) and sub-tasks (e.g.
/etc/init/postgresql.conf ? 'postgresql' task to start/stop whole
postgresql and /etc/init/postgresql/instance.conf ?
'postgresql/instance' describing each instance) instead.

Greets,
        Jacek


From patrys at pld-linux.org  Wed May  5 11:20:30 2010
From: patrys at pld-linux.org (Patryk Zawadzki)
Date: Wed, 5 May 2010 11:20:30 +0200
Subject: Native upstart scripts
In-Reply-To: <20100504091741.GA31617@jajo.eggsoft>
References: <20100504091741.GA31617@jajo.eggsoft>
Message-ID: <y2h89b6ba3a1005050220k16ff5111h28cbacaa2d1f4b3c@mail.gmail.com>

On Tue, May 4, 2010 at 11:17 AM, Jacek Konieczny <jajcus at jajcus.net> wrote:
> Hello,
>
> In PLD Th, we have upstart as the /sbin/init daemon for some time, but
> it is only used to start the old 'SysVinit' scripts from
> /etc/rc.d/init.d. To make full use of Upstart features, like process
> supervising, parallel start, etc. we should find a way to include
> Upstart support in our packages. Though, we should not replace the
> current, working solution.

BTW: http://0pointer.de/blog/projects/systemd.html

-- 
Patryk Zawadzki


From jajcus at jajcus.net  Wed May  5 12:31:55 2010
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Wed, 5 May 2010 12:31:55 +0200
Subject: Native upstart scripts
In-Reply-To: <y2h89b6ba3a1005050220k16ff5111h28cbacaa2d1f4b3c@mail.gmail.com>
References: <20100504091741.GA31617@jajo.eggsoft>
	<y2h89b6ba3a1005050220k16ff5111h28cbacaa2d1f4b3c@mail.gmail.com>
Message-ID: <20100505103155.GA22652@jajo.eggsoft>

On Wed, May 05, 2010 at 11:20:30AM +0200, Patryk Zawadzki wrote:
> On Tue, May 4, 2010 at 11:17 AM, Jacek Konieczny <jajcus at jajcus.net> wrote:
> > In PLD Th, we have upstart as the /sbin/init daemon for some time, but
> > it is only used to start the old 'SysVinit' scripts from
> > /etc/rc.d/init.d. To make full use of Upstart features, like process
> > supervising, parallel start, etc. we should find a way to include
> > Upstart support in our packages. Though, we should not replace the
> > current, working solution.
> 
> BTW: http://0pointer.de/blog/projects/systemd.html

Great. This fixes some problems of Upstart? but?

This would look great to me if I haven't seen several other ?great
SysVinit replacements?. All of them were much better than SysVinit and
even had some ?working implementations?. Often long before the Upstart
came up. And everybody have been still using SysVinit.

Upstart is the only one which caught on. It is terrible, with its
big incompatibilities between each version? poor documentation (at least
on the web), impractical event system. Nevertheless it is still much
better than SysVinit with the pile of shell scripts starting daemons
doing anything not to be managed (double-forking, etc.).

Unfortunately /sbin/init is so critical, that we cannot even experiment
much, especially with something no one else uses. And it is hard to have
multiple /sbin/init implementation side by side in one distribution.
They all differ too much not only in the configuration file formats but
in the whole philosophy of the configuration (not only ?how to describe
a service configuration? but even ?what is a service configuration?). 

One could think of making some kind of an abstraction layer, like our
rc-inetd, but that is a very bad idea. We would probably lose most of
the advantages of each init implementation then.

We should rather think how can we provided a few very different
configuration items, each for a different init implementation, with one
package. I am losing my enthusiasm about implementing the ?native
upstart support? in PLD when I think systemd may eventually mature
enough and we would need to start from the beginning?

And I need a good init system now. Currently I use SysVinit +
daemontools in my PLD-based project. It generally works, but is not
elegant nor optimal. Even upstart, when properly deployed, would be
better and systemd could be much better, but I guess it is a matter of
future. 

Pozdrowienia,
        Jacek


From jajcus at jajcus.net  Wed May  5 12:34:34 2010
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Wed, 5 May 2010 12:34:34 +0200
Subject: Native upstart scripts
In-Reply-To: <201005041940.43253.glen@delfi.ee>
References: <20100504091741.GA31617@jajo.eggsoft>
	<201005041940.43253.glen@delfi.ee>
Message-ID: <20100505103433.GB22652@jajo.eggsoft>

On Tue, May 04, 2010 at 07:40:43PM +0300, Elan Ruusam?e wrote:
> i don't like the idea that the links are managed via some script, i'd like 
> easily to boot to upstart-mode or sysvinit-mode with a kernel commandline, or 
> something in /etc/sysconfig/system the both solutions should be available and 
> configured at the same time.

I thought about that and cannot see how it could be implemented. When
there are upstart configs for some services then Upstart will start them
by the dependencies inside and I cannot see a way to stop this from a
kernel command line and still have the flexibility of which services
should be handled by Upstart and which the old way.

Greets,
        Jacek


From deejay1 at srem.org  Wed May  5 14:03:10 2010
From: deejay1 at srem.org (=?UTF-8?B?xYF1a2FzeiBKZXJuYcWb?=)
Date: Wed, 5 May 2010 14:03:10 +0200
Subject: Native upstart scripts
In-Reply-To: <y2h89b6ba3a1005050220k16ff5111h28cbacaa2d1f4b3c@mail.gmail.com>
References: <20100504091741.GA31617@jajo.eggsoft>
	<y2h89b6ba3a1005050220k16ff5111h28cbacaa2d1f4b3c@mail.gmail.com>
Message-ID: <i2z77fcfd0a1005050503p2d9535cfo8a48b6a773cc0571@mail.gmail.com>

On Wed, May 5, 2010 at 11:20 AM, Patryk Zawadzki <patrys at pld-linux.org> wrote:
> On Tue, May 4, 2010 at 11:17 AM, Jacek Konieczny <jajcus at jajcus.net> wrote:
>> Hello,
>>
>> In PLD Th, we have upstart as the /sbin/init daemon for some time, but
>> it is only used to start the old 'SysVinit' scripts from
>> /etc/rc.d/init.d. To make full use of Upstart features, like process
>> supervising, parallel start, etc. we should find a way to include
>> Upstart support in our packages. Though, we should not replace the
>> current, working solution.
>
> BTW: http://0pointer.de/blog/projects/systemd.html

Well, after seeing how many people have weird problems with PulseAudio
I would be cautious about using another thing  thought out by
Lennart...

-- 
?ukasz [DeeJay1] Jerna?


From patrys at pld-linux.org  Wed May  5 14:13:51 2010
From: patrys at pld-linux.org (Patryk Zawadzki)
Date: Wed, 5 May 2010 14:13:51 +0200
Subject: Native upstart scripts
In-Reply-To: <i2z77fcfd0a1005050503p2d9535cfo8a48b6a773cc0571@mail.gmail.com>
References: <20100504091741.GA31617@jajo.eggsoft>
	<y2h89b6ba3a1005050220k16ff5111h28cbacaa2d1f4b3c@mail.gmail.com>
	<i2z77fcfd0a1005050503p2d9535cfo8a48b6a773cc0571@mail.gmail.com>
Message-ID: <v2l89b6ba3a1005050513m6ceb6380v7fb8e66fd1a299aa@mail.gmail.com>

On Wed, May 5, 2010 at 2:03 PM, ?ukasz Jerna? <deejay1 at srem.org> wrote:
> Well, after seeing how many people have weird problems with PulseAudio
> I would be cautious about using another thing ?thought out by
> Lennart...

To be fair you have to admit that a vast number of the problems
experienced while using pulseaudio are actually bugs in kernel audio
modules and/or alsa API abuse (think opal, ekiga etc.).

-- 
Patryk Zawadzki


From jajcus at jajcus.net  Wed May  5 14:32:19 2010
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Wed, 5 May 2010 14:32:19 +0200
Subject: Native upstart scripts
In-Reply-To: <v2l89b6ba3a1005050513m6ceb6380v7fb8e66fd1a299aa@mail.gmail.com>
References: <20100504091741.GA31617@jajo.eggsoft>
	<y2h89b6ba3a1005050220k16ff5111h28cbacaa2d1f4b3c@mail.gmail.com>
	<i2z77fcfd0a1005050503p2d9535cfo8a48b6a773cc0571@mail.gmail.com>
	<v2l89b6ba3a1005050513m6ceb6380v7fb8e66fd1a299aa@mail.gmail.com>
Message-ID: <20100505123219.GC22652@jajo.eggsoft>

On Wed, May 05, 2010 at 02:13:51PM +0200, Patryk Zawadzki wrote:
> On Wed, May 5, 2010 at 2:03 PM, ?ukasz Jerna? <deejay1 at srem.org> wrote:
> > Well, after seeing how many people have weird problems with PulseAudio
> > I would be cautious about using another thing ?thought out by
> > Lennart...
> 
> To be fair you have to admit that a vast number of the problems
> experienced while using pulseaudio are actually bugs in kernel audio
> modules and/or alsa API abuse (think opal, ekiga etc.).

I would rather say it is because of putting another audio server where
it is not needed at all. ALSA alone does its job well enough nowadays
(and if it does not, it should be fixed not wrapped with another layer).
Fortunately things have not gone too far yet and a system without
PulseAudio can still be set up (there was no such freedom in the dark
ages of ESD and ARTS).

This /sbin/init things are not that easy. We will always need some init
daemon? though I still won't chose an implementation only basing on the
fact that the idea is great. It must work and be maintained (or at least
stable as SysVinit) too.

Greets,
        Jacek


From patrys at pld-linux.org  Wed May  5 15:48:18 2010
From: patrys at pld-linux.org (Patryk Zawadzki)
Date: Wed, 5 May 2010 15:48:18 +0200
Subject: Native upstart scripts
In-Reply-To: <20100505123219.GC22652@jajo.eggsoft>
References: <20100504091741.GA31617@jajo.eggsoft>
	<y2h89b6ba3a1005050220k16ff5111h28cbacaa2d1f4b3c@mail.gmail.com>
	<i2z77fcfd0a1005050503p2d9535cfo8a48b6a773cc0571@mail.gmail.com>
	<v2l89b6ba3a1005050513m6ceb6380v7fb8e66fd1a299aa@mail.gmail.com>
	<20100505123219.GC22652@jajo.eggsoft>
Message-ID: <z2o89b6ba3a1005050648zd0e09f77w5c8ea9e396507d54@mail.gmail.com>

On Wed, May 5, 2010 at 2:32 PM, Jacek Konieczny <jajcus at jajcus.net> wrote:
> I would rather say it is because of putting another audio server where
> it is not needed at all. ALSA alone does its job well enough nowadays
> (and if it does not, it should be fixed not wrapped with another layer).
> Fortunately things have not gone too far yet and a system without
> PulseAudio can still be set up (there was no such freedom in the dark
> ages of ESD and ARTS).

I'd say alsa has nothing to search in the userspace and should just
expose hardware. It should not try to provide smart mixing, store
per-application volume or decide which channels to mute when a voip
connection is established. That's pulseaudio's work.

> This /sbin/init things are not that easy. We will always need some init
> daemon? though I still won't chose an implementation only basing on the
> fact that the idea is great. It must work and be maintained (or at least
> stable as SysVinit) too.

Notice I only mentioned systemd as "by the way". I did not even think
about packaging it at this point in time.

-- 
Patryk Zawadzki


From jajcus at jajcus.net  Wed May  5 16:19:46 2010
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Wed, 5 May 2010 16:19:46 +0200
Subject: Native upstart scripts
In-Reply-To: <z2o89b6ba3a1005050648zd0e09f77w5c8ea9e396507d54@mail.gmail.com>
References: <20100504091741.GA31617@jajo.eggsoft>
	<y2h89b6ba3a1005050220k16ff5111h28cbacaa2d1f4b3c@mail.gmail.com>
	<i2z77fcfd0a1005050503p2d9535cfo8a48b6a773cc0571@mail.gmail.com>
	<v2l89b6ba3a1005050513m6ceb6380v7fb8e66fd1a299aa@mail.gmail.com>
	<20100505123219.GC22652@jajo.eggsoft>
	<z2o89b6ba3a1005050648zd0e09f77w5c8ea9e396507d54@mail.gmail.com>
Message-ID: <20100505141946.GG22652@jajo.eggsoft>

On Wed, May 05, 2010 at 03:48:18PM +0200, Patryk Zawadzki wrote:
> > This /sbin/init things are not that easy. We will always need some init
> > daemon? though I still won't chose an implementation only basing on the
> > fact that the idea is great. It must work and be maintained (or at least
> > stable as SysVinit) too.
> 
> Notice I only mentioned systemd as "by the way". I did not even think
> about packaging it at this point in time.

Yes, but knowing it ?by the way? means we can consider it as a future
option when changing rc-scripts for Upstart, so we don't have to revert
some silly changes in the far future.

Greets,
        Jacek


From glen at delfi.ee  Thu May  6 13:07:04 2010
From: glen at delfi.ee (Elan =?iso-8859-1?q?Ruusam=E4e?=)
Date: Thu, 6 May 2010 14:07:04 +0300
Subject: repcached
Message-ID: <201005061407.04635.glen@delfi.ee>

hi there

what you think about repcached http://repcached.lab.klab.org/ 

should we create new package, or just patch our memcached?

-- 
glen


From radek42 at gmail.com  Thu May  6 22:24:30 2010
From: radek42 at gmail.com (=?UTF-8?B?UmFkb3PFgmF3IFppZWxpxYRza2k=?=)
Date: Thu, 6 May 2010 15:24:30 -0500
Subject: repcached
In-Reply-To: <201005061407.04635.glen@delfi.ee>
References: <201005061407.04635.glen@delfi.ee>
Message-ID: <p2ma8dae1ea1005061324p994e5f82xaf40efec6c14d431@mail.gmail.com>

2010/5/6 Elan Ruusam?e <glen at delfi.ee>:
> what you think about repcached http://repcached.lab.klab.org/
> should we create new package, or just patch our memcached?

New.  Leave this kind of patching to the upstream.
You can't get this functionality without a performance hit.

Anyway, if you need to replicate your cache (can't afford to lose it),
you're doing it wrong.


From patrys at pld-linux.org  Thu May  6 22:27:46 2010
From: patrys at pld-linux.org (Patryk Zawadzki)
Date: Thu, 6 May 2010 22:27:46 +0200
Subject: repcached
In-Reply-To: <p2ma8dae1ea1005061324p994e5f82xaf40efec6c14d431@mail.gmail.com>
References: <201005061407.04635.glen@delfi.ee>
	<p2ma8dae1ea1005061324p994e5f82xaf40efec6c14d431@mail.gmail.com>
Message-ID: <k2u89b6ba3a1005061327t48e371a0u22ee7c6b87cd370d@mail.gmail.com>

2010/5/6 Rados?aw Zieli?ski <radek42 at gmail.com>:
> 2010/5/6 Elan Ruusam?e <glen at delfi.ee>:
>> what you think about repcached http://repcached.lab.klab.org/
>> should we create new package, or just patch our memcached?
> New. ?Leave this kind of patching to the upstream.
> You can't get this functionality without a performance hit.

+1

> Anyway, if you need to replicate your cache (can't afford to lose it),
> you're doing it wrong.

Sometimes it's not about "not losing the cache" but about
invalidating/refreshing all the redundant caches at precisely the same
point in time.

-- 
Patryk Zawadzki


From glen at pld-linux.org  Fri May  7 09:13:54 2010
From: glen at pld-linux.org (Elan =?utf-8?q?Ruusam=C3=A4e?=)
Date: Fri, 7 May 2010 10:13:54 +0300
Subject: repcached
In-Reply-To: <k2u89b6ba3a1005061327t48e371a0u22ee7c6b87cd370d@mail.gmail.com>
References: <201005061407.04635.glen@delfi.ee>
	<p2ma8dae1ea1005061324p994e5f82xaf40efec6c14d431@mail.gmail.com>
	<k2u89b6ba3a1005061327t48e371a0u22ee7c6b87cd370d@mail.gmail.com>
Message-ID: <201005071013.54788.glen@pld-linux.org>

On Thursday 06 May 2010 23:27:46 Patryk Zawadzki wrote:
> 2010/5/6 Rados?aw Zieli?ski <radek42 at gmail.com>:
> > 2010/5/6 Elan Ruusam?e <glen at delfi.ee>:
> >> what you think about repcached http://repcached.lab.klab.org/
> >> should we create new package, or just patch our memcached?
> >
> > New. ?Leave this kind of patching to the upstream.
> > You can't get this functionality without a performance hit.

yet it's not enabled by default, but via -x and -X option

keeping it separate package is burden for maintaining it (at least for me), 
i.e duplicating the initscripts and config, apparently need to do some extra 
work not to conflict with paths if memcached is installed to same host as 
well.

yet i'm not sure how evasive it is to the core usage, few if-statements in 
code really such a notable perforamance drop?

yet separate package allows you clearly distinguish is it upstream memcached 
or rep-cache patched memcached.

so far i added as bcond to memcached.spec as it's against my free will to 
duplicate code.

-- 
glen


From wrobell at pld-linux.org  Fri May  7 09:56:49 2010
From: wrobell at pld-linux.org (Artur Wroblewski)
Date: Fri, 7 May 2010 08:56:49 +0100
Subject: repcached
In-Reply-To: <201005061407.04635.glen@delfi.ee>
References: <201005061407.04635.glen@delfi.ee>
Message-ID: <v2k950d18961005070056w3b86e235mdd1e42d0c67854fc@mail.gmail.com>

2010/5/6 Elan Ruusam?e <glen at delfi.ee>:
> hi there
>
> what you think about repcached http://repcached.lab.klab.org/
>
> should we create new package, or just patch our memcached?

have repcached guys ever proposed the patch to memcached
authors and what was the outcome?

as well, problem can be with newer versions of memcached
and repcached not catching up, then you have to disable it
from time to time or wait.

regards,

w


From jajcus at jajcus.net  Fri May  7 15:33:21 2010
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Fri, 7 May 2010 15:33:21 +0200
Subject: Native upstart scripts =?utf-8?B?4oCTIGlt?=
	=?utf-8?Q?plemented?=
In-Reply-To: <20100504091741.GA31617@jajo.eggsoft>
References: <20100504091741.GA31617@jajo.eggsoft>
Message-ID: <20100507133321.GE4406@jajo.eggsoft>

Hello,

Your volunteer has done his job :)

I have made the proof-of-concept implementation of native upstart job
control. I did it a bit different way than I initially suggested ?
taking into account your comments and improving my own ideas by trial
and errors.

My main requirements were fulfilled:
  - this doesn't break current /etc/rc.d/init.d/* scripts
  - this can coexist with the current /etc/rc.d/init.d/* script based
    job control
  - /etc/init.d/* scripts are quite LSB compatible even when the jobs
    are controlled by upstart.

Currently all the changes are applied to 'upstart_native' branch, so the
solution may be tested before merging into the distribution. As it
doesn't seem to break anything I guess it can be merged very soon (after
the weekend?) unless someone shows me some big problem with the code or
has a good idea on how some things could be done better.

I have modified:

  - rc-scripts 
        to provide facilities needed for upstart-controlled services
  - syslog-ng
        as an example of a generic service implementation other services
        rely on ? how to make job depend on a 'syslog' service not 
        a specific 'syslog-ng' implementation
  - openssh-server
        as an example of some system service relying on network and
        syslog
  - postgresql
        as an example of multi-instance service. It also shows how
        to run a service with non-root uid (it is strange upstart
        doesn't provide this function directly)

To play with that build rc-scripts, syslog-ng, openssh and postgresql
from the 'upstart_native' branch, upgrade to these builds (this should
change nothing in how your system works) and then install
syslog-ng-upstart, openssh-upstart and postgresql-upstart.

When the *-upstart packages are installed you can still control the
services with /sbin/service or /etc/rc.d/init.d/$service scripts
or directly with the 'initctl' tool.

The way it is implemented gives two options of booting the PLD system:

1. the traditional ? serialized, slow but verbose and colorful way 
       ? just do not install the *-upstart packaged or boot with
         'pld.no-upstart'

2. the new event-based, parallelized, auto-respawning way, but less
  verbose
        - instal the *-upstart packages and let them do their job

Some documentation for the rc-scripts+upstart usage is here:

  http://svn.pld-linux.org/cgi-bin/viewsvn/rc-scripts/branches/upstart_native/doc/upstart.txt?rev=11395&view=markup


Patryk Zawadzki <patrys at pld-linux.org> wrote:
> I'd opt for having 2 separate -init subpackages, one with the current
> rc.d contents and one with an upstart job description and a simple
> rc.d wrapper that runs "start $foo", "stop $foo" etc.

-upstart subpackages done. Addin "-init" makes no sense, as current
upstart job handling implementaion relies on the init.d scripts for LSB
compatibility and doing things not doable with bare Upstart
(non-SIGHUP-reloading, 'checkconfig', advanced status monitoring).

Elan Ruusam?e <glen at delfi.ee> wrote:
> i don't like the idea that the links are managed via some script, i'd like
> easily to boot to upstart-mode or sysvinit-mode with a kernel commandline, or
> something in /etc/sysconfig/system the both solutions should be available and
> configured at the same time.

Done. No chkconfig patching, no script-managed-links, only a minor
update do /sbin/service added.

The new, upstart event-based boot may be disabled by a kernel command
line option: "pld.no-upstart".

> also i'd not invent new paths, but use /etc/init for upstart scripts.

Done. But this has some consequences:

- The package-provided /etc/init/*.conf files are config files. Expect
  user to modify them in any way. Do not put things, that may change on
  every upgrade, there.
- Package-provided job description could conflict with used locally or
  provided by third-party packages. I suggest using
  /etc/init/local/*.conf for local jobs and keeping /etc/init/*.conf
  files for /etc/rc.d/init.d/* equivalents (put extra jobs needed for
  the functionality into a subdirectory)

Greets,
        Jacek


From sparky at pld-linux.org  Sat May  8 15:54:46 2010
From: sparky at pld-linux.org (Przemyslaw Iskra)
Date: Sat, 8 May 2010 15:54:46 +0200
Subject: poldek -r broken again?
In-Reply-To: <B0346DE5-1288-446B-8C63-B0E7C2F62483@mac.com>
References: <20100502153814.GB4912@davabel.touk.pl>
	<20100502181139.GA2210@pld-linux.org>
	<668B3D2A-5768-4313-9CF1-179899A1C70B@mac.com>
	<20100502184501.GA4640@pld-linux.org>
	<286CF004-CDD6-43AD-B77E-46C2FE79948C@mac.com>
	<20100502191436.GA10776@pld-linux.org>
	<B0346DE5-1288-446B-8C63-B0E7C2F62483@mac.com>
Message-ID: <20100508135446.GA26237@pld-linux.org>

On Sun, May 02, 2010 at 03:23:32PM -0400, Jeff Johnson wrote:
> 
> Send along a patch if you want a fix. The code is in lib/psm.c,
> and the patch is likely less than 5 lines (which is >2 orders of magnitude
> fewer lines than have already been written about Glen's %pretrans script)

That should do it for rpm 5:

http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/~checkout~/packages/rpm/rpm-lua-exit-chroot-correctly.patch

I didn't test it, but very similar change in rpm 4.5 fixed the problem.


-- 
 ____  Sparky{PI] -- Przemyslaw _  ___  _  _  ........... LANG...Pl..Ca..Es..En
/____) ___  ___  _ _ || Iskra  |  | _ \| |  | : WWW........ppcrcd.pld-linux.org
\____\| -_)'___| ||^'||//\\// <   |  _/| |  | : JID......sparky<at>jabberes.org
(____/||   (_-_|_||  ||\\ ||   |_ |_|  |_| _| : Mail....sparky<at>pld-linux.org


From glen at pld-linux.org  Sat May  8 16:07:35 2010
From: glen at pld-linux.org (Elan =?utf-8?q?Ruusam=C3=A4e?=)
Date: Sat, 8 May 2010 17:07:35 +0300
Subject: Native upstart scripts =?utf-8?q?=E2=80=93?= implemented
In-Reply-To: <20100507133321.GE4406@jajo.eggsoft>
References: <20100504091741.GA31617@jajo.eggsoft>
	<20100507133321.GE4406@jajo.eggsoft>
Message-ID: <201005081707.36094.glen@pld-linux.org>

On Friday 07 May 2010 16:33:21 Jacek Konieczny wrote:
> Some documentation for the rc-scripts+upstart usage is here:
>
> ?
> http://svn.pld-linux.org/cgi-bin/viewsvn/rc-scripts/branches/upstart_native
>/doc/upstart.txt?rev=11395&view=markup

does $JOB=_ has special meaning?

...
    emit starting JOB=_ SERVICE=syslog


-- 
glen


From jajcus at jajcus.net  Sat May  8 17:03:58 2010
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Sat, 8 May 2010 17:03:58 +0200
Subject: Native upstart scripts =?utf-8?B?4oCT?= =?utf-8?Q?_implemented?=
In-Reply-To: <201005081707.36094.glen@pld-linux.org>
References: <20100504091741.GA31617@jajo.eggsoft>
	<20100507133321.GE4406@jajo.eggsoft>
	<201005081707.36094.glen@pld-linux.org>
Message-ID: <20100508150358.GA3716@lolek.nigdzie>

On Sat, May 08, 2010 at 05:07:35PM +0300, Elan Ruusam?e wrote:
> On Friday 07 May 2010 16:33:21 Jacek Konieczny wrote:
> > Some documentation for the rc-scripts+upstart usage is here:
> >
> > ?
> > http://svn.pld-linux.org/cgi-bin/viewsvn/rc-scripts/branches/upstart_native
> >/doc/upstart.txt?rev=11395&view=markup
> 
> does $JOB=_ has special meaning?

No, as far as I know.
 
> ...
>     emit starting JOB=_ SERVICE=syslog

I thought init script should not emit 'started' event exactly as a job
would do, but then I changed my mind. I guess I have not update the doc
after I have changed the script.

Greets,
        Jacek


From glen at pld-linux.org  Sat May  8 21:41:07 2010
From: glen at pld-linux.org (Elan =?iso-8859-1?q?Ruusam=E4e?=)
Date: Sat, 8 May 2010 22:41:07 +0300
Subject: Native upstart scripts
In-Reply-To: <20100504091741.GA31617@jajo.eggsoft>
References: <20100504091741.GA31617@jajo.eggsoft>
Message-ID: <201005082241.07245.glen@pld-linux.org>

On Tuesday 04 May 2010 12:17:41 Jacek Konieczny wrote:
> What do you think? Should I try to prepare a proof-of-concept
> implementation?

any plans of moving rc.sysinit also to upstart?

-- 
glen


From jajcus at jajcus.net  Sat May  8 22:25:27 2010
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Sat, 8 May 2010 22:25:27 +0200
Subject: Native upstart scripts
In-Reply-To: <201005082241.07245.glen@pld-linux.org>
References: <20100504091741.GA31617@jajo.eggsoft>
	<201005082241.07245.glen@pld-linux.org>
Message-ID: <20100508202527.GA6163@lolek.nigdzie>

On Sat, May 08, 2010 at 10:41:07PM +0300, Elan Ruusam?e wrote:
> On Tuesday 04 May 2010 12:17:41 Jacek Konieczny wrote:
> > What do you think? Should I try to prepare a proof-of-concept
> > implementation?
> 
> any plans of moving rc.sysinit also to upstart?

No. I don't think we would gain a lot. Reimplementing all these stuff
via Upstart keeping all this working may be quite difficult and
maintaining both will be a hell.

And no, switching fully to Upstart at this point is not a good idea.
Have anybody recently upgraded upstart 0.5 to 0.6 on a production
machine? Have anybody used 'expect daemon' instead of 'expect fork' or
made a similar mistake? Any of these would break such system so it won't
even shut down or reboot properly.

Upstart is great in many points much much better than SysVinit. But it
is not ready to be the only option for a distribution. Let's add upstart
support to more and more packages, but do not make it a critical
component of a PLD system.

Greets,
        Jacek


From glen at pld-linux.org  Sun May  9 00:05:20 2010
From: glen at pld-linux.org (Elan =?iso-8859-1?q?Ruusam=E4e?=)
Date: Sun, 9 May 2010 01:05:20 +0300
Subject: Native upstart scripts
In-Reply-To: <20100508202527.GA6163@lolek.nigdzie>
References: <20100504091741.GA31617@jajo.eggsoft>
	<201005082241.07245.glen@pld-linux.org>
	<20100508202527.GA6163@lolek.nigdzie>
Message-ID: <201005090105.27629.glen@pld-linux.org>

On Saturday 08 May 2010 23:25:27 Jacek Konieczny wrote:
> And no, switching fully to Upstart at this point is not a good idea.
> Have anybody recently upgraded upstart 0.5 to 0.6 on a production
> machine?

i've upgraded once. there was no way to reload init process. the TERM signal 
which was supposed to work did not work, maybe it needed patching in 0.5.x 
times to work.

and even now with 0.6.x the reloading of init process imho did not work.
as a result you can't shutdown your system in normal ways. likely reboot -f 
will help there.

# telinit u
# lsof -p 1 | grep /sbin/init
init      1 root  txt    REG      254,0   112932 50978332 /sbin/init (deleted)

-- 
glen


From glen at delfi.ee  Sun May  9 01:52:57 2010
From: glen at delfi.ee (Elan =?utf-8?q?Ruusam=C3=A4e?=)
Date: Sun, 9 May 2010 02:52:57 +0300
Subject: Native upstart scripts =?utf-8?q?=E2=80=93?= implemented
In-Reply-To: <20100507133321.GE4406@jajo.eggsoft>
References: <20100504091741.GA31617@jajo.eggsoft>
	<20100507133321.GE4406@jajo.eggsoft>
Message-ID: <201005090252.57685.glen@pld-linux.org>

On Friday 07 May 2010 16:33:21 Jacek Konieczny wrote:
> Patryk Zawadzki <patrys at pld-linux.org> wrote:
> > I'd opt for having 2 separate -init subpackages, one with the current
> > rc.d contents and one with an upstart job description and a simple
> > rc.d wrapper that runs "start $foo", "stop $foo" etc.
>
> -upstart subpackages done. Addin "-init" makes no sense, as current
> upstart job handling implementaion relies on the init.d scripts for LSB
> compatibility and doing things not doable with bare Upstart
> (non-SIGHUP-reloading, 'checkconfig', advanced status monitoring).

i'd rather avoid completely the new subpackage here, if needed move 
the /etc/init dir to filesystem package to avoid dirdeps pulling upstart, and 
use conflicts tag for the current requires tag.

> Some documentation for the rc-scripts+upstart usage is here:
>
> http://svn.pld-linux.org/cgi-bin/viewsvn/rc-scripts/branches/upstart_native
>/doc/upstart.txt?rev=11395&view=markup

syslog-ng/syslog-ng.init:
...
upstart_controlled --except configtest

i don't really understand how flush-logs is handled, or it's just not 
perfectly implemented yet? also how do you specify multiple excludes remains 
unclear.

also, configtest before reload/restart action would be really important to 
have in upstart as well, considering that we restart services on rpm 
upgrades. does upstart have such concept after all as restart/reload in 
scripts?

ps: would be nice to know where's source of documentation, for example i did 
not find myself description of job file directives.

-- 
glen


From jajcus at jajcus.net  Sun May  9 08:57:57 2010
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Sun, 9 May 2010 08:57:57 +0200
Subject: Native upstart scripts =?utf-8?B?4oCT?= =?utf-8?Q?_implemented?=
In-Reply-To: <201005090252.57685.glen@pld-linux.org>
References: <20100504091741.GA31617@jajo.eggsoft>
	<20100507133321.GE4406@jajo.eggsoft>
	<201005090252.57685.glen@pld-linux.org>
Message-ID: <20100509065757.GA3572@lolek.nigdzie>

On Sun, May 09, 2010 at 02:52:57AM +0300, Elan Ruusam?e wrote:
> i'd rather avoid completely the new subpackage here, if needed move 
> the /etc/init dir to filesystem package to avoid dirdeps pulling upstart, and 
> use conflicts tag for the current requires tag.

Patrys asked for subpackages and it makes sense - the easiest to choose 
between upstart-way and the-old-way per package.
 
> syslog-ng/syslog-ng.init:
> ...
> upstart_controlled --except configtest
> 
> i don't really understand how flush-logs is handled,

It is not. 'service syslog-ng flush-logs' will tell you that. On the
other hand - with upstart 'reload' does the same.
Of course, flush-logs can be implemented in the init script. I guess it
should if it is used by anything else (logrotate?)

> also how do you specify multiple excludes remains unclear.

When '--except' is used, then all what follows are the excludes.

> also, configtest before reload/restart action would be really important to 
> have in upstart as well, considering that we restart services on rpm 
> upgrades. does upstart have such concept after all as restart/reload in 
> scripts?

No. 'reload' in upstart is 'kill -HUP', anything else must be
re-implemented in the init script.  Restart is 'stop; start'. Hmmm...
Now I can see 'restart with configtest' may be easily implemented.
Whenever '--except configtest'  is used, 'upstart_controlled' can call
configtest before trying restart.

configtest on start makes little sense with upstart IMHO.

> ps: would be nice to know where's source of documentation, for example i did 
> not find myself description of job file directives.

>From the rc-scripts init.txt:

 The syntax of the ``/etc/init/*.conf`` files is described in the
 init(5) man page.


And yes, looking for a current Upstart documentation in the web gives
no good results.

Greets,
        Jacek


From qboosh at pld-linux.org  Sun May  9 08:59:27 2010
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Sun, 9 May 2010 08:59:27 +0200
Subject: packages: util-linux-ng/util-linux-ng.spec -
	ramsize/rdev/rootflags/vidmode...
In-Reply-To: <packages_util_linux_ng_util_linux_ng.spec.1.69@pld-linux.org>
References: <packages_util_linux_ng_util_linux_ng.spec.1.68@pld-linux.org>
	<packages_util_linux_ng_util_linux_ng.spec.1.69@pld-linux.org>
Message-ID: <20100509065927.GA6063@stranger.qboosh.pl>

On Sun, May 09, 2010 at 01:20:20AM +0200, glen wrote:
> Author: glen                         Date: Sat May  8 23:20:20 2010 GMT
> Module: packages                      Tag: HEAD
> ---- Log message:
> - ramsize/rdev/rootflags/vidmode present on alpha and sparc as well

Maybe, but they have no use on non-x86 kernel images.


-- 
Jakub Bogusz    http://qboosh.pl/


From qboosh at pld-linux.org  Sun May  9 09:00:13 2010
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Sun, 9 May 2010 09:00:13 +0200
Subject: packages: util-linux-ng/util-linux-ng.spec - manfiles fix for
	ramsizerdevro...
In-Reply-To: <packages_util_linux_ng_util_linux_ng.spec.1.71@pld-linux.org>
References: <packages_util_linux_ng_util_linux_ng.spec.1.70@pld-linux.org>
	<packages_util_linux_ng_util_linux_ng.spec.1.71@pld-linux.org>
Message-ID: <20100509070013.GB6063@stranger.qboosh.pl>

On Sun, May 09, 2010 at 02:54:22AM +0200, glen wrote:
> Author: glen                         Date: Sun May  9 00:54:22 2010 GMT
> Module: packages                      Tag: HEAD
> ---- Log message:
> - manfiles fix for ramsizerdevrootflagsvidmode pages on non-intels
> 
> ---- Files affected:
> packages/util-linux-ng:
>    util-linux-ng.spec (1.70 -> 1.71) 
> 
> ---- Diffs:
> 
> ================================================================
> Index: packages/util-linux-ng/util-linux-ng.spec
> diff -u packages/util-linux-ng/util-linux-ng.spec:1.70 packages/util-linux-ng/util-linux-ng.spec:1.71
> --- packages/util-linux-ng/util-linux-ng.spec:1.70	Sun May  9 01:27:49 2010
> +++ packages/util-linux-ng/util-linux-ng.spec	Sun May  9 02:54:17 2010
> @@ -664,9 +664,7 @@
>  	$RPM_BUILD_ROOT%{_mandir}/*/man5/nfs.5 \
>  	$RPM_BUILD_ROOT%{_mandir}/*/man8/{elvtune,setfdprm,sln,raw}.8
>  
> -%ifnarch %{ix86} %{x8664}
>  rm -f $RPM_BUILD_ROOT%{_mandir}/*/man8/{ramsize,rdev,rootflags,vidmode}.8
> -%endif

Why are killing rdev manuals?


-- 
Jakub Bogusz    http://qboosh.pl/


From glen at delfi.ee  Sun May  9 10:21:56 2010
From: glen at delfi.ee (Elan =?iso-8859-1?q?Ruusam=E4e?=)
Date: Sun, 9 May 2010 11:21:56 +0300
Subject: Native upstart scripts =?utf-8?q?=E2=80=93?= implemented
In-Reply-To: <20100509065757.GA3572@lolek.nigdzie>
References: <20100504091741.GA31617@jajo.eggsoft>
	<201005090252.57685.glen@pld-linux.org>
	<20100509065757.GA3572@lolek.nigdzie>
Message-ID: <201005091121.58246.glen@pld-linux.org>

On Sunday 09 May 2010 09:57:57 Jacek Konieczny wrote:
> On Sun, May 09, 2010 at 02:52:57AM +0300, Elan Ruusam?e wrote:
> > i'd rather avoid completely the new subpackage here, if needed move
> > the /etc/init dir to filesystem package to avoid dirdeps pulling upstart,
> > and use conflicts tag for the current requires tag.
>
> Patrys asked for subpackages and it makes sense - the easiest to choose
> between upstart-way and the-old-way per package.

that maybe useful for developer, but not for end user who wants to boot 
fastest way using upstart, as he does not know which upstart packages he must 
install, i.e must inspect every package one by one, seeing if he has the same 
base package installed on system or not.


-- 
glen


From glen at delfi.ee  Sun May  9 10:39:14 2010
From: glen at delfi.ee (Elan =?utf-8?q?Ruusam=C3=A4e?=)
Date: Sun, 9 May 2010 11:39:14 +0300
Subject: Native upstart scripts =?utf-8?q?=E2=80=93?= implemented
In-Reply-To: <20100507133321.GE4406@jajo.eggsoft>
References: <20100504091741.GA31617@jajo.eggsoft>
	<20100507133321.GE4406@jajo.eggsoft>
Message-ID: <201005091139.15121.glen@pld-linux.org>

On Friday 07 May 2010 16:33:21 Jacek Konieczny wrote:
> Hello,
>
> Your volunteer has done his job :)

seems there's some deadlock with initctl emiting

also seems the "nice service name" is lost there (see sshd part).

also seems there's no our typical restart service after package upgrade,
if you've upgrading upstart-enabled service.
%define upstart_post() \
    if [ -f /var/lock/subsys/"%1" ] ; then \
        /sbin/service --no-upstart "%1" stop \
        /sbin/service "%1" start \
    fi

anyway, ps of stall:
root     25974  0.4  0.5  15596  6064 pts/3    S+   11:23   0:00          \_ poldek -u upstart --up --sn carme openssh-server-upstart syslog-ng-upstart
root     27078  0.4  0.5  12516  5804 pts/3    S+   11:24   0:00              \_ 
rpm --upgrade -vh --root / /var/cache/poldek/http_carme.pld-linux.org..glen.th.i686/syslog-ng-3.0.5-2.1.i
root     27181  0.0  0.0   1872   584 pts/3    S+   11:24   0:00                  \_ /bin/sh /home/users/glen/tmp/rpm-tmp.59975 2
root     27184  0.0  0.0   1872   604 pts/3    S+   11:24   0:00                      \_ /bin/sh /sbin/service syslog-ng restart
root     27187  0.0  0.0   2000   808 pts/3    S+   11:24   0:00                          \_ /bin/sh /etc/rc.d/init.d/syslog-ng restart
root     27321  0.0  0.0   5716   972 pts/3    S+   11:24   0:00                              \_ /sbin/initctl emit started JOB=syslog-ng SERVICE=syslog

and terminal output:

11:23:03 root[load: 5.81; cpu: 68c]@ravenous ~# poldek -u upstart --up --sn carme openssh-server-upstart syslog-ng-upstart
...
Preparing...                ########################################### [100%]
   1:rc-scripts             ########################################### [ 25%]
   2:openssh                ########################################### [ 50%]
   3:openssh-server         ########################################### [ 75%]
 * Reloading OpenSSH service.......................................[ DONE ]
   4:openssh-server-upstart ########################################### [100%]
 * Stopping OpenSSH service........................................[ DONE ]
 * Starting sshd service...........................................[ DONE ]

Installing set #2
Processing dependencies...
syslog-ng-upstart-3.0.5-2.1.i686 marks syslog-ng-3.0.5-2.1.i686 (cap syslog-ng = 3.0.5-2.1)
 syslog-ng-3.0.5-1.i686 obsoleted by syslog-ng-3.0.5-2.1.i686
There are 2 packages to install (1 marked by dependencies), 1 to remove:
I syslog-ng-upstart-3.0.5-2.1.i686
D syslog-ng-3.0.5-2.1.i686
R syslog-ng-3.0.5-1.i686
This operation will use 423.0B of disk space.
Need to get 2.7MB of archives (2.7MB to download).

Retrieving carme::syslog-ng-3.0.5-2.1.i686.rpm...
.............................. 100.0% [2.7M (450.6K/s)]                      
Retrieving carme::syslog-ng-upstart-3.0.5-2.1.i686.rpm...
.............................. 100.0% [4.2K (4.2K/s)]                   
Executing rpm --upgrade -vh --root /...
error: failed to stat /mnt/docs: Host is down
Preparing...                ########################################### [100%]
   1:syslog-ng              ########################################### [ 50%]
 * Stopping syslog-ng service......................................[ DONE ]
 * Starting syslog-ng service......................................[ DONE ]

# strace -p 27321  
Process 27321 attached - interrupt to quit
restart_syscall(<... resuming interrupted call ...>

# lsof -p 27321  
lsof: WARNING: can't stat() fuse.gvfs-fuse-daemon file system /home/users/glen/.gvfs
      Output information may be incomplete.
lsof: WARNING: can't stat() cifs file system /mnt/docs
      Output information may be incomplete.
COMMAND   PID USER   FD   TYPE     DEVICE  SIZE/OFF     NODE NAME
initctl 27321 root  cwd    DIR      254,0      4096      128 /
initctl 27321 root  rtd    DIR      254,0      4096      128 /
initctl 27321 root  txt    REG      254,0    121084 50978235 /sbin/initctl
initctl 27321 root  mem    REG      254,0 109740720   142782 /usr/lib/locale/locale-archive
initctl 27321 root  mem    REG      254,0    117047 34830808 /lib/libpthread-2.11.1.so
initctl 27321 root  mem    REG      254,0     26512 35528163 /lib/librt-2.11.1.so
initctl 27321 root  mem    REG      254,0   1339736 33654733 /lib/libc-2.11.1.so
initctl 27321 root  mem    REG      254,0    214980 34344577 /lib/libdbus-1.so.3.4.0
initctl 27321 root  mem    REG      254,0     33996 33600976 /lib/libnih-dbus.so.1.0.0
initctl 27321 root  mem    REG      254,0     83156 33632425 /lib/libnih.so.1.0.0
initctl 27321 root  mem    REG      254,0    132403 33596389 /lib/ld-2.11.1.so
initctl 27321 root    0r  FIFO        0,8       0t0  1228197 pipe
initctl 27321 root    1u   CHR      136,7       0t0       10 /dev/pts/7
initctl 27321 root    2u   CHR      136,7       0t0       10 /dev/pts/7
initctl 27321 root    3u  unix 0xdb670a00       0t0  1228587 socket

-- 
glen


From jajcus at jajcus.net  Sun May  9 11:00:57 2010
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Sun, 9 May 2010 11:00:57 +0200
Subject: Native upstart scripts =?utf-8?B?4oCT?= =?utf-8?Q?_implemented?=
In-Reply-To: <201005091139.15121.glen@pld-linux.org>
References: <20100504091741.GA31617@jajo.eggsoft>
	<20100507133321.GE4406@jajo.eggsoft>
	<201005091139.15121.glen@pld-linux.org>
Message-ID: <20100509090057.GA3619@lolek.nigdzie>

On Sun, May 09, 2010 at 11:39:14AM +0300, Elan Ruusam?e wrote:
> On Friday 07 May 2010 16:33:21 Jacek Konieczny wrote:
> > Hello,
> >
> > Your volunteer has done his job :)
> 
> seems there's some deadlock with initctl emiting

Isn't that another result of https://bugs.launchpad.net/upstart/+bug/406397

> also seems the "nice service name" is lost there (see sshd part).

How is that supposed to work and where is that 'sshd part'?

> also seems there's no our typical restart service after package upgrade,
> if you've upgrading upstart-enabled service.
> %define upstart_post() \
>     if [ -f /var/lock/subsys/"%1" ] ; then \
>         /sbin/service --no-upstart "%1" stop \
>         /sbin/service "%1" start \
>     fi

The service will be restarted after main package upgrade. Though we have
the real problem of -upstart subpackage here: the restart should
probably be done when both main and -upstart packages are upgraded.

> anyway, ps of stall:
> root     25974  0.4  0.5  15596  6064 pts/3    S+   11:23   0:00          \_ poldek -u upstart --up --sn carme openssh-server-upstart syslog-ng-upstart
> root     27078  0.4  0.5  12516  5804 pts/3    S+   11:24   0:00              \_ 
> rpm --upgrade -vh --root / /var/cache/poldek/http_carme.pld-linux.org..glen.th.i686/syslog-ng-3.0.5-2.1.i
> root     27181  0.0  0.0   1872   584 pts/3    S+   11:24   0:00                  \_ /bin/sh /home/users/glen/tmp/rpm-tmp.59975 2
> root     27184  0.0  0.0   1872   604 pts/3    S+   11:24   0:00                      \_ /bin/sh /sbin/service syslog-ng restart
> root     27187  0.0  0.0   2000   808 pts/3    S+   11:24   0:00                          \_ /bin/sh /etc/rc.d/init.d/syslog-ng restart
> root     27321  0.0  0.0   5716   972 pts/3    S+   11:24   0:00                              \_ /sbin/initctl emit started JOB=syslog-ng SERVICE=syslog

I guess  --no-wait for emit should be used here. Though there is
something blocking ? emit waits for some action on the 'started' event
to finish and some service starting on this even has probably locked up
(most probably due to https://bugs.launchpad.net/upstart/+bug/406397 and
broken /etc/init/*.conf file (I have recently fixed those for openssh
and syslog-ng)).

Greets,
        Jacek


From glen at delfi.ee  Sun May  9 11:26:56 2010
From: glen at delfi.ee (Elan =?utf-8?q?Ruusam=C3=A4e?=)
Date: Sun, 9 May 2010 12:26:56 +0300
Subject: Native upstart scripts =?utf-8?q?=E2=80=93?= implemented
In-Reply-To: <20100509090057.GA3619@lolek.nigdzie>
References: <20100504091741.GA31617@jajo.eggsoft>
	<201005091139.15121.glen@pld-linux.org>
	<20100509090057.GA3619@lolek.nigdzie>
Message-ID: <201005091226.57206.glen@pld-linux.org>

On Sunday 09 May 2010 12:00:57 Jacek Konieczny wrote:
> > also seems the "nice service name" is lost there (see sshd part).
>
> How is that supposed to work and where is that 'sshd part'?

line 1 and 3 - the "nice name", line 4 "plain service name"

1:?* Reloading OpenSSH service.......................................[ DONE ]
2:? ?4:openssh-server-upstart ########################################### 
[100%]
3:?* Stopping OpenSSH service........................................[ DONE ]
4:?* Starting sshd service...........................................[ DONE ]

the nice names are embedded in initscript as msg_* and in .spec file as extra 
arg for %service restart

-- 
glen


From glen at delfi.ee  Sun May  9 11:51:19 2010
From: glen at delfi.ee (Elan =?utf-8?q?Ruusam=C3=A4e?=)
Date: Sun, 9 May 2010 12:51:19 +0300
Subject: Native upstart scripts =?utf-8?q?=E2=80=93?= implemented
In-Reply-To: <20100509090057.GA3619@lolek.nigdzie>
References: <20100504091741.GA31617@jajo.eggsoft>
	<201005091139.15121.glen@pld-linux.org>
	<20100509090057.GA3619@lolek.nigdzie>
Message-ID: <201005091251.19662.glen@pld-linux.org>

On Sunday 09 May 2010 12:00:57 Jacek Konieczny wrote:
> I guess ?--no-wait for emit should be used here. Though there is
> something blocking ? emit waits for some action on the 'started' event
> to finish and some service starting on this even has probably locked up
> (most probably due to https://bugs.launchpad.net/upstart/+bug/406397 and
> broken /etc/init/*.conf file (I have recently fixed those for openssh
> and syslog-ng)).

if thats any useful info, then initctl list:

# initctl list
mountall-net stop/waiting
rc stop/waiting
ureadahead-other stop/waiting
sshd start/running, process 26834
tty (/dev/tty3) start/running, process 4362
tty (/dev/tty2) start/running, process 27957
tty (/dev/tty1) start/running, process 4358
tty (/dev/tty4) start/running, process 4364
control-alt-delete stop/waiting
mountall stop/waiting
rcS stop/waiting
mountall-reboot stop/waiting
mountall-shell stop/waiting
start-ttys stop/waiting
rcS-sulogin stop/waiting
ureadahead stop/waiting

i've built packages today, sshd is irrelevant here even if it has recent -D 
fix, and syslog-ng is not yet known as upstart service, package install is 
not yet finished.

# pkgbytime | grep upstart
Tue Apr 20 20:42:46 2010 vim-syntax-upstart-0.1-1.noarch
Sun May  2 21:26:26 2010 upstart-SysVinit-2.86-24.i686
Sun May  9 11:22:01 2010 upstart-0.6.5-2.2.i686
Sun May  9 11:24:18 2010 openssh-server-upstart-5.5p1-2.1.i686

# initctl status syslog
initctl: Unknown job: syslog
# initctl status syslog-ng
initctl: Unknown job: syslog-ng

-- 
glen


From jajcus at jajcus.net  Sun May  9 11:59:15 2010
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Sun, 9 May 2010 11:59:15 +0200
Subject: Native upstart scripts =?utf-8?B?4oCT?= =?utf-8?Q?_implemented?=
In-Reply-To: <201005091226.57206.glen@pld-linux.org>
References: <20100504091741.GA31617@jajo.eggsoft>
	<201005091139.15121.glen@pld-linux.org>
	<20100509090057.GA3619@lolek.nigdzie>
	<201005091226.57206.glen@pld-linux.org>
Message-ID: <20100509095915.GB3619@lolek.nigdzie>

On Sun, May 09, 2010 at 12:26:56PM +0300, Elan Ruusam?e wrote:
> On Sunday 09 May 2010 12:00:57 Jacek Konieczny wrote:
> > > also seems the "nice service name" is lost there (see sshd part).
> >
> > How is that supposed to work and where is that 'sshd part'?
> 
> line 1 and 3 - the "nice name", line 4 "plain service name"

> 3:?* Stopping OpenSSH service........................................[ DONE ]
> 4:?* Starting sshd service...........................................[ DONE ]

Oh, you mean that. Do you have an idea how to solve this, keeping things
simple? 

I don't won't anything overly complicated for such a trivial cosmetic
problem. Especially that these messages will not be displayed on boot,
only during manual start/stop with 'service' or during package install
or upgrades, when user knows what is happening.

Greets,
        Jacek


From qboosh at pld-linux.org  Sun May  9 13:58:49 2010
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Sun, 9 May 2010 13:58:49 +0200
Subject: libuuid-dietlibc
Message-ID: <20100509115849.GA4237@stranger.qboosh.pl>

It seems that libuuid-dietlibc should have its own pkgconfig file
(in /usr/lib/dietlibc/pkgconfig?), specifying additional -lcompat,
because dietlibc libc.a doesn't contain syscall():

/usr/lib/dietlibc/lib-i386/libuuid.a(gen_uuid.o): In function `get_random_bytes':
(.text+0x1d6): undefined reference to `syscall'
/usr/lib/dietlibc/lib-i386/libuuid.a(gen_uuid.o): In function `get_random_bytes':
(.text+0x236): undefined reference to `syscall'
collect2: ld returned 1 exit status


-- 
Jakub Bogusz    http://qboosh.pl/


From jajcus at jajcus.net  Mon May 10 08:48:28 2010
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Mon, 10 May 2010 08:48:28 +0200
Subject: Native upstart scripts =?utf-8?B?4oCT?= =?utf-8?Q?_implemented?=
In-Reply-To: <201005090252.57685.glen@pld-linux.org>
References: <20100504091741.GA31617@jajo.eggsoft>
	<20100507133321.GE4406@jajo.eggsoft>
	<201005090252.57685.glen@pld-linux.org>
Message-ID: <20100510064827.GB4097@jajo.eggsoft>

On Sun, May 09, 2010 at 02:52:57AM +0300, Elan Ruusam?e wrote:
> also, configtest before reload/restart action would be really important to 
> have in upstart as well, considering that we restart services on rpm 
> upgrades.

Done. Not for 'initctl reload' (which is only 'kill -HUP'), but for
'service $name {restart|reload|try-restart|force-reload}'. Works when
the init script has 'configtest' action and 'upstart_controlled --except
configtest'

Greets,
        Jacek


From glen at delfi.ee  Mon May 10 17:41:47 2010
From: glen at delfi.ee (Elan =?iso-8859-1?q?Ruusam=E4e?=)
Date: Mon, 10 May 2010 18:41:47 +0300
Subject: SVN: rc-scripts/branches/upstart_native/rc.d/init.d/functions
In-Reply-To: <11411@svn.pld-linux.org>
References: <11411@svn.pld-linux.org>
Message-ID: <201005101841.48170.glen@delfi.ee>

On Monday 10 May 2010 09:40:34 jajcus wrote:
> Author: jajcus
> Date: Mon May 10 08:40:34 2010
> New Revision: 11411
>
> Modified:
>    rc-scripts/branches/upstart_native/rc.d/init.d/functions
> Log:
> - use 'configtest' before restart/reload if available
[..]
>  		reload)
> +			if is_yes $has_configtest ; then
> +				"$script" configtest || exit 1
> +			fi

perhaps we standardize this, i.e if "configtest" shell function is available, 
then use that shell function instead of invoking script again.

as invoking itself again, is slow, /bin/sh and huge init.d/functions slow 
things down.

-- 
glen


From jajcus at jajcus.net  Mon May 10 18:12:04 2010
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Mon, 10 May 2010 18:12:04 +0200
Subject: SVN: rc-scripts/branches/upstart_native/rc.d/init.d/functions
In-Reply-To: <201005101841.48170.glen@delfi.ee>
References: <11411@svn.pld-linux.org>
 <201005101841.48170.glen@delfi.ee>
Message-ID: <20100510161204.GF3644@lolek.nigdzie>

On Mon, May 10, 2010 at 06:41:47PM +0300, Elan Ruusam?e wrote:
> On Monday 10 May 2010 09:40:34 jajcus wrote:
> > Author: jajcus
> > Date: Mon May 10 08:40:34 2010
> > New Revision: 11411
> >
> > Modified:
> >    rc-scripts/branches/upstart_native/rc.d/init.d/functions
> > Log:
> > - use 'configtest' before restart/reload if available
> [..]
> >  		reload)
> > +			if is_yes $has_configtest ; then
> > +				"$script" configtest || exit 1
> > +			fi
> 
> perhaps we standardize this, i.e if "configtest" shell function is available, 
> then use that shell function instead of invoking script again.

Yes. That is a good idea. I just prefer no to start from optimizing
things. Let's make it work first. :)

Greets,
        Jacek


From baggins at sith.mimuw.edu.pl  Tue May 11 11:47:04 2010
From: baggins at sith.mimuw.edu.pl (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Tue, 11 May 2010 11:47:04 +0200
Subject: libuuid-dietlibc
In-Reply-To: <20100509115849.GA4237@stranger.qboosh.pl>
References: <20100509115849.GA4237@stranger.qboosh.pl>
Message-ID: <20100511094704.GD3720@sith.mimuw.edu.pl>

On Sun, 09 May 2010, Jakub Bogusz wrote:

> It seems that libuuid-dietlibc should have its own pkgconfig file
> (in /usr/lib/dietlibc/pkgconfig?), specifying additional -lcompat,
> because dietlibc libc.a doesn't contain syscall():

Making pkgconfig file is simple, teaching programs to use it is harder.
IMO it's enough to hack the build process to just use -lcompat if
needed. What was the package that failed to build?

-- 
Jan R?korajski            |  ALL SUSPECTS ARE GUILTY. PERIOD!
baggins<at>mimuw.edu.pl   |  OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY?
BOFH, MANIAC              |                   -- TROOPS by Kevin Rubio


From sparky at pld-linux.org  Sat May 15 02:39:37 2010
From: sparky at pld-linux.org (Przemyslaw Iskra)
Date: Sat, 15 May 2010 02:39:37 +0200
Subject: packages: sudoscript/sudoscript.spec (NEW),
	sudoscript/sudoscript-init.patc...
In-Reply-To: <packages_sudoscript_sudoscript_init.patch.1.1@pld-linux.org>
References: <packages_sudoscript_sudoscript.spec.NONE@pld-linux.org>
	<packages_sudoscript_sudoscript_init.patch.NONE@pld-linux.org>
	<packages_sudoscript_sudoscript_init.patch.1.1@pld-linux.org>
Message-ID: <20100515003937.GA13942@pld-linux.org>

On Sat, May 15, 2010 at 12:39:48AM +0200, mguevara wrote:

> +%define	__make	/usr/bin/make -j1

Those macros are not for you to redefine. Just put -j1 in each
invocation. If you really want to define it globally in spec make it
based on that predefined macro (%expand is your friend).

> +BuildRequires:	perl
> +Requires:	perl

Should be perl-base, and perl-modules if needed.


P.S. "make -j8 -j1" is not wrong. Don't be frightened when you see it.


-- 
 ____  Sparky{PI] -- Przemyslaw _  ___  _  _  ........... LANG...Pl..Ca..Es..En
/____) ___  ___  _ _ || Iskra  |  | _ \| |  | : WWW........ppcrcd.pld-linux.org
\____\| -_)'___| ||^'||//\\// <   |  _/| |  | : JID......sparky<at>jabberes.org
(____/||   (_-_|_||  ||\\ ||   |_ |_|  |_| _| : Mail....sparky<at>pld-linux.org


From z at xatka.net  Tue May 18 20:45:31 2010
From: z at xatka.net (=?iso-8859-2?Q?Pawe=B3?= Zuzelski)
Date: Tue, 18 May 2010 20:45:31 +0200
Subject: Serverside CVS rename
Message-ID: <20100518184531.GA4037@davabel.xatka.net>

Please, rename jira-enterprise to jira. Project name has changed
recently.

-- 
Regards,
Pawe?


From glen at delfi.ee  Wed May 19 10:29:05 2010
From: glen at delfi.ee (Elan =?iso-8859-2?q?Ruusam=E4e?=)
Date: Wed, 19 May 2010 11:29:05 +0300
Subject: Serverside CVS rename
In-Reply-To: <20100518184531.GA4037@davabel.xatka.net>
References: <20100518184531.GA4037@davabel.xatka.net>
Message-ID: <201005191129.20302.glen@delfi.ee>

On Tuesday 18 May 2010 21:45:31 Pawe? Zuzelski wrote:
> Please, rename jira-enterprise to jira. Project name has changed
> recently.

done mv

-- 
glen


From z at xatka.net  Wed May 19 10:56:15 2010
From: z at xatka.net (=?iso-8859-2?Q?Pawe=B3?= Zuzelski)
Date: Wed, 19 May 2010 10:56:15 +0200
Subject: packages: vimpager/README (NEW) - initial - taken from webpage
In-Reply-To: <packages_vimpager_README.1.1@pld-linux.org>
References: <packages_vimpager_README.NONE@pld-linux.org>
	<packages_vimpager_README.1.1@pld-linux.org>
Message-ID: <20100519085615.GA4415@davabel.touk.pl>

On Wed, 19 May 2010, uzsolt wrote:
> +Put these in your ~/.bashrc or ~/.zshrc 

What about ksh users? :) I'd write "in your shell config, for
example ~/.bashrc or ~/.zshrc.".

> + alias less=$PAGER

This is not good advice in my opinion. All programs that need to
display a lot of text data should support PAGER env (and many do,
like man, perldoc, git). 'less' means run 'less', not the default
pager. Sometimes user may need to run less even if he use vimpager
as default pager. For example vimpager does not support less' -R
option so it is unable to display file containing terminal color
codes.

-- 
Regards,
Pawe?


From udvzsolt at gmail.com  Wed May 19 15:27:45 2010
From: udvzsolt at gmail.com (Zsolt Udvari)
Date: Wed, 19 May 2010 15:27:45 +0200
Subject: packages: vimpager/README (NEW) - initial - taken from webpage
In-Reply-To: <20100519085615.GA4415@davabel.touk.pl>
References: <packages_vimpager_README.NONE@pld-linux.org>
	<packages_vimpager_README.1.1@pld-linux.org>
	<20100519085615.GA4415@davabel.touk.pl>
Message-ID: <AANLkTimcw_dmCqDaX-Qa0E5XydsONx-c6v9XvJckaIUZ@mail.gmail.com>

> What about ksh users? :) I'd write "in your shell config, for
> example ~/.bashrc or ~/.zshrc.".
I copied from webpage. If you use ksh and you feel that you're
discriminated, correct it :)


>> + alias less=$PAGER
>
> This is not good advice in my opinion. All programs that need to
> display a lot of text data should support PAGER env (and many do,
> like man, perldoc, git). 'less' means run 'less', not the default
> pager. Sometimes user may need to run less even if he use vimpager
> as default pager. For example vimpager does not support less' -R
> option so it is unable to display file containing terminal color
> codes.
And what is your suggestion? Should delete this "advice"?

Zsolt


From z at xatka.net  Wed May 19 16:12:38 2010
From: z at xatka.net (=?iso-8859-2?Q?Pawe=B3?= Zuzelski)
Date: Wed, 19 May 2010 16:12:38 +0200
Subject: packages: vimpager/README (NEW) - initial - taken from webpage
In-Reply-To: <AANLkTimcw_dmCqDaX-Qa0E5XydsONx-c6v9XvJckaIUZ@mail.gmail.com>
References: <packages_vimpager_README.NONE@pld-linux.org>
	<packages_vimpager_README.1.1@pld-linux.org>
	<20100519085615.GA4415@davabel.touk.pl>
	<AANLkTimcw_dmCqDaX-Qa0E5XydsONx-c6v9XvJckaIUZ@mail.gmail.com>
Message-ID: <20100519141238.GB4415@davabel.touk.pl>

On Wed, 19 May 2010, Zsolt Udvari wrote:

> > What about ksh users? :) I'd write "in your shell config, for
> > example ~/.bashrc or ~/.zshrc.".
> I copied from webpage. If you use ksh and you feel that you're
> discriminated, correct it :)

ok ok :)
otoh if someone uses non-default, he knows how to configure it...

> >> + alias less=$PAGER
> >
> > This is not good advice in my opinion. All programs that need to
> > display a lot of text data should support PAGER env (and many do,
> > like man, perldoc, git). 'less' means run 'less', not the default
> > pager. Sometimes user may need to run less even if he use vimpager
> > as default pager. For example vimpager does not support less' -R
> > option so it is unable to display file containing terminal color
> > codes.
> And what is your suggestion? Should delete this "advice"?

In my opinion - yes.

-- 
Pawe?


From jajcus at jajcus.net  Wed May 19 22:07:40 2010
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Wed, 19 May 2010 22:07:40 +0200
Subject: packages: vimpager/README (NEW) - initial - taken from webpage
In-Reply-To: <20100519141238.GB4415@davabel.touk.pl>
References: <packages_vimpager_README.NONE@pld-linux.org>
	<packages_vimpager_README.1.1@pld-linux.org>
	<20100519085615.GA4415@davabel.touk.pl>
	<AANLkTimcw_dmCqDaX-Qa0E5XydsONx-c6v9XvJckaIUZ@mail.gmail.com>
	<20100519141238.GB4415@davabel.touk.pl>
Message-ID: <20100519200740.GA3999@lolek.nigdzie>

On Wed, May 19, 2010 at 04:12:38PM +0200, Pawe? Zuzelski wrote:
> > >> + alias less=$PAGER
> > >
> > And what is your suggestion? Should delete this "advice"?
> 
> In my opinion - yes.

+1

Greets,
        Jacek


From udvzsolt at gmail.com  Thu May 20 06:04:03 2010
From: udvzsolt at gmail.com (Zsolt Udvari)
Date: Thu, 20 May 2010 06:04:03 +0200
Subject: packages: vimpager/README (NEW) - initial - taken from webpage
In-Reply-To: <20100519200740.GA3999@lolek.nigdzie>
References: <packages_vimpager_README.NONE@pld-linux.org>
	<packages_vimpager_README.1.1@pld-linux.org>
	<20100519085615.GA4415@davabel.touk.pl>
	<AANLkTimcw_dmCqDaX-Qa0E5XydsONx-c6v9XvJckaIUZ@mail.gmail.com>
	<20100519141238.GB4415@davabel.touk.pl>
	<20100519200740.GA3999@lolek.nigdzie>
Message-ID: <AANLkTinZd_Z2enkFzOJ_LHM8L5BrHxwhyMpbJ2e8oZR5@mail.gmail.com>

>> > >> + alias less=$PAGER
>> > >
>> > And what is your suggestion? Should delete this "advice"?
>>
>> In my opinion - yes.
>
> +1
Modified...

Zsolt


From qboosh at pld-linux.org  Fri May 21 09:09:23 2010
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Fri, 21 May 2010 09:09:23 +0200
Subject: packages: dev/dev.spec - Release 5.   Set attr(666, root,
	root)  /dev/shm   H...
In-Reply-To: <packages_dev_dev.spec.1.193@pld-linux.org>
References: <packages_dev_dev.spec.1.192@pld-linux.org>
	<packages_dev_dev.spec.1.193@pld-linux.org>
Message-ID: <20100521070923.GD6063@stranger.qboosh.pl>

On Fri, May 21, 2010 at 09:00:49AM +0200, matkor wrote:
> Author: matkor                       Date: Fri May 21 07:00:49 2010 GMT
> Module: packages                      Tag: HEAD
> ---- Log message:
> - Release 5.
>   Set attr(666,root,root)  /dev/shm
>   Having mounted /dev/shm with defualts from  /etc/fstab and upgrading dev
>   results in permision change resulting apps using shmem to get privs error

> @@ -170,7 +170,7 @@
>  %attr(660,root,video) /dev/radio
>  %attr(660,root,audio) /dev/sequencer2
>  %attr(600,root,root) /dev/sg[0-7]
> -%dir /dev/shm
> +%attr(666,root,root) %dir /dev/shm
>  %dir /dev/snd
>  %attr(660,root,video) /dev/vbi
>  %attr(660,root,video) /dev/video

666 for dir?!

Also wrong, allows foreign files to be deleted by everyone.

fstab setting is 1777.


-- 
Jakub Bogusz    http://qboosh.pl/


From jajcus at jajcus.net  Fri May 21 12:27:16 2010
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Fri, 21 May 2010 12:27:16 +0200
Subject: packages: dev/dev.spec - Release 5.   Set attr(666, root,
	root)  /dev/shm   H...
In-Reply-To: <20100521070923.GD6063@stranger.qboosh.pl>
References: <packages_dev_dev.spec.1.192@pld-linux.org>
	<packages_dev_dev.spec.1.193@pld-linux.org>
	<20100521070923.GD6063@stranger.qboosh.pl>
Message-ID: <20100521102715.GB12774@jajo.eggsoft>

On Fri, May 21, 2010 at 09:09:23AM +0200, Jakub Bogusz wrote:
> > -%dir /dev/shm
> > +%attr(666,root,root) %dir /dev/shm
> 
> 666 for dir?!

Insane, indeed. Evil even ;)

> Also wrong, allows foreign files to be deleted by everyone.
> 
> fstab setting is 1777.

Yes. And that is ok only when tmpfs is actually mounted there. We don't
want this a place for any user to fill-up the root partition.

Standard 0755 looks ok to me for the dev package contents (the SHM mount
point).

Greets,
        Jacek


From jajcus at jajcus.net  Fri May 21 17:39:01 2010
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Fri, 21 May 2010 17:39:01 +0200
Subject: packages: dev/dev.spec - Release 5.   Set attr(666, root,
	root)  /dev/shm   H...
In-Reply-To: <201005211606.21373.mateusz@ant.gliwice.pl>
References: <packages_dev_dev.spec.1.192@pld-linux.org>
	<20100521070923.GD6063@stranger.qboosh.pl>
	<20100521102715.GB12774@jajo.eggsoft>
	<201005211606.21373.mateusz@ant.gliwice.pl>
Message-ID: <20100521153900.GA3456@lolek.nigdzie>

On Fri, May 21, 2010 at 04:06:20PM +0200, Mateusz Korniak wrote:
> I wish I could avoid scenario:
> I have working mounted /dev/shm (1777) and I do update o dev package which 
> changes permissions back do default, breaking any application using shm :/

Yes, that sucks. But leaving 1777 /dev/shm on the root partition without
tmpfs mounted is not optimal either.

> Any solutions ?

Do not package this directory at all (or as %ghost) and create the mount
point on runtime?

Greets,
        Jacek


From qboosh at pld-linux.org  Fri May 21 17:44:44 2010
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Fri, 21 May 2010 17:44:44 +0200
Subject: packages: dev/dev.spec - Release 5.   Set attr(666, root,
	root)  /dev/shm   H...
In-Reply-To: <201005211606.21373.mateusz@ant.gliwice.pl>
References: <packages_dev_dev.spec.1.192@pld-linux.org>
	<20100521070923.GD6063@stranger.qboosh.pl>
	<20100521102715.GB12774@jajo.eggsoft>
	<201005211606.21373.mateusz@ant.gliwice.pl>
Message-ID: <20100521154444.GA10033@mail>

On Fri, May 21, 2010 at 04:06:20PM +0200, Mateusz Korniak wrote:
> On Friday 21 of May 2010, Jacek Konieczny wrote:
> > > Also wrong, allows foreign files to be deleted by everyone.
> > > fstab setting is 1777.
> > 
> > Yes. And that is ok only when tmpfs is actually mounted there. We don't
> > want this a place for any user to fill-up the root partition.
> > 
> > Standard 0755 looks ok to me for the dev package contents (the SHM mount
> > point).
> 
> I wish I could avoid scenario:
> I have working mounted /dev/shm (1777) and I do update o dev package which 
> changes permissions back do default, breaking any application using shm :/
> Any solutions ?

Add /dev/shm to _netsharedpath (or how it is called, I don't remember
exactly now)?


-- 
Jakub Bogusz    http://qboosh.pl/


From qboosh at pld-linux.org  Mon May 24 09:48:17 2010
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Mon, 24 May 2010 09:48:17 +0200
Subject: packages: zlib/zlib-lfs.patch (NEW) - new
In-Reply-To: <packages_zlib_zlib_lfs.patch.1.1@pld-linux.org>
References: <packages_zlib_zlib_lfs.patch.NONE@pld-linux.org>
	<packages_zlib_zlib_lfs.patch.1.1@pld-linux.org>
Message-ID: <20100524074817.GA4571@stranger.qboosh.pl>

On Sun, May 23, 2010 at 10:21:26PM +0200, adamg wrote:
> Author: adamg                        Date: Sun May 23 20:21:26 2010 GMT
> Module: packages                      Tag: HEAD
> ---- Log message:
> - new
> 
> ---- Files affected:
> packages/zlib:
>    zlib-lfs.patch (NONE -> 1.1)  (NEW)
> 
> ---- Diffs:
> 
> ================================================================
> Index: packages/zlib/zlib-lfs.patch
> diff -u /dev/null packages/zlib/zlib-lfs.patch:1.1
> --- /dev/null	Sun May 23 22:21:26 2010
> +++ packages/zlib/zlib-lfs.patch	Sun May 23 22:21:21 2010
> @@ -0,0 +1,22 @@
> +Improper condition was introduced in 1.2.5 causing some applications
> +(e.g. cgit) to fail due to conflicting declarations.
> +
> +References:
> +- http://mail.madler.net/pipermail/zlib-devel_madler.net/2010-May/002249.html
> +- http://bugs.debian.org/439980
> +- http://bugs.gentoo.org/show_bug.cgi?id=316377
> +- http://bugs.gentoo.org/show_bug.cgi?id=316855
> +- http://bugs.archlinux.org/task/19280
> +- https://bugs.launchpad.net/ubuntu/+source/libpciaccess/+bug/402178
> +
> +--- zlib-1.2.5/zlib.h~	2010-04-20 06:12:48.000000000 +0200
> ++++ zlib-1.2.5/zlib.h	2010-05-23 22:11:29.241572099 +0200
> +@@ -1578,7 +1578,7 @@
> + #  define gzoffset gzoffset64
> + #  define adler32_combine adler32_combine64
> + #  define crc32_combine crc32_combine64
> +-#  ifdef _LARGEFILE64_SOURCE
> ++#  ifndef _LARGEFILE64_SOURCE
> +      ZEXTERN gzFile ZEXPORT gzopen64 OF((const char *, const char *));
> +      ZEXTERN z_off_t ZEXPORT gzseek64 OF((gzFile, z_off_t, int));
> +      ZEXTERN z_off_t ZEXPORT gztell64 OF((gzFile));

I bet this is wrong: it declares *64 functions as operating on z_off_t
type, which is 32-bit on 32-bit archs.
Actual functions operate on 64-bit z_off64_t.
The patch can lead to problems at runtime (it may be tested e.g. with
gzseek).


-- 
Jakub Bogusz    http://qboosh.pl/


From marcin.rybak at gmail.com  Mon May 24 21:45:16 2010
From: marcin.rybak at gmail.com (Marcin Rybak)
Date: Mon, 24 May 2010 21:45:16 +0200
Subject: lighttpd-1.4.26 mod_auth.patch
Message-ID: <AANLkTim5rLF_RLIZljOVuaYu4mDSo0-WaW98PqC0hNyf@mail.gmail.com>

Hi,

Because - default lighttpd mod_auth does not provide additional information
about source IP address when login attempt is wrong (as an example - while
password guessing), i made some change in a source code.

here's how it looks by default:

2010-05-24 21:00:36: (http_auth.c.872) get_password failed

and after patching:

2010-05-24 21:00:48: (http_auth.c.872) get_password failed , IP: xx.xx.xx.xx

it is now possible to use as an example fail2ban - to prevent login/password
bruteforce attacks

please find attached http_auth.patch (tested at my th i686) (my first patch,
so please be soft :) )

regards,
---
Marcin Rybak
http://marcinrybak.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: http_auth.patch
Type: application/octet-stream
Size: 496 bytes
Desc: not available
URL: </mailman/pipermail/pld-devel-en/attachments/20100524/b16d22d4/attachment.obj>

From glen at delfi.ee  Tue May 25 10:39:21 2010
From: glen at delfi.ee (Elan =?iso-8859-15?q?Ruusam=E4e?=)
Date: Tue, 25 May 2010 11:39:21 +0300
Subject: lighttpd-1.4.26 mod_auth.patch
In-Reply-To: <AANLkTim5rLF_RLIZljOVuaYu4mDSo0-WaW98PqC0hNyf@mail.gmail.com>
References: <AANLkTim5rLF_RLIZljOVuaYu4mDSo0-WaW98PqC0hNyf@mail.gmail.com>
Message-ID: <201005251139.21750.glen@delfi.ee>

On Monday 24 May 2010 22:45:16 Marcin Rybak wrote:
> please find attached http_auth.patch (tested at my th i686) (my first
> patch, so please be soft :) )

applied, with fixes, you missed new format parameter, weird that it even 
worked for you.

and usually it's good idea to send patches upstream first

> regards,
> ---
> Marcin Rybak
> http://marcinrybak.com

-- 
glen


From jajcus at jajcus.net  Tue May 25 13:51:42 2010
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Tue, 25 May 2010 13:51:42 +0200
Subject: packages: ntp/ntp.spec - net-snmp-ntpd and mibs-ntp
	subpackages, agent seem...
In-Reply-To: <packages_ntp_ntp.spec.1.138@pld-linux.org>
References: <packages_ntp_ntp.spec.1.137@pld-linux.org>
	<packages_ntp_ntp.spec.1.138@pld-linux.org>
Message-ID: <20100525115142.GA29829@jajo.eggsoft>

On Tue, May 25, 2010 at 01:05:37PM +0200, glen wrote:
> Author: glen                         Date: Tue May 25 11:05:37 2010 GMT
> Module: packages                      Tag: HEAD
> ---- Log message:
> - net-snmp-ntpd and mibs-ntp subpackages, agent seems working

Are you sure 'net-snmp' is the right name for this? This is not a part
of net-snmp project...

Greets,
        Jacek


From arekm at maven.pl  Tue May 25 14:06:01 2010
From: arekm at maven.pl (Arkadiusz Miskiewicz)
Date: Tue, 25 May 2010 14:06:01 +0200
Subject: packages: ntp/ntp.spec - net-snmp-ntpd and mibs-ntp subpackages,
	agent seem...
In-Reply-To: <20100525115142.GA29829@jajo.eggsoft>
References: <packages_ntp_ntp.spec.1.137@pld-linux.org>
	<packages_ntp_ntp.spec.1.138@pld-linux.org>
	<20100525115142.GA29829@jajo.eggsoft>
Message-ID: <201005251406.02272.arekm@maven.pl>

On Tuesday 25 of May 2010, Jacek Konieczny wrote:
> On Tue, May 25, 2010 at 01:05:37PM +0200, glen wrote:
> > Author: glen                         Date: Tue May 25 11:05:37 2010 GMT
> > Module: packages                      Tag: HEAD
> > ---- Log message:
> > - net-snmp-ntpd and mibs-ntp subpackages, agent seems working
> 
> Are you sure 'net-snmp' is the right name for this? This is not a part
> of net-snmp project...

Just like perl* are not part of perl project, php-* and python-*, too.

> 
> Greets,
>         Jacek
> _______________________________________________
> pld-devel-en mailing list
> pld-devel-en at lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


-- 
Arkadiusz Mi?kiewicz        PLD/Linux Team
arekm / maven.pl            http://ftp.pld-linux.org/


From gotar at polanet.pl  Tue May 25 14:28:29 2010
From: gotar at polanet.pl (Tomasz Pala)
Date: Tue, 25 May 2010 14:28:29 +0200
Subject: packages: ntp/ntp.spec - net-snmp-ntpd and mibs-ntp subpackages,
	agent seem...
In-Reply-To: <201005251406.02272.arekm@maven.pl>
References: <packages_ntp_ntp.spec.1.137@pld-linux.org>
	<packages_ntp_ntp.spec.1.138@pld-linux.org>
	<20100525115142.GA29829@jajo.eggsoft>
	<201005251406.02272.arekm@maven.pl>
Message-ID: <20100525122829.GA21664@polanet.pl>

On Tue, May 25, 2010 at 14:06:01 +0200, Arkadiusz Miskiewicz wrote:

>> > - net-snmp-ntpd and mibs-ntp subpackages, agent seems working
>> 
>> Are you sure 'net-snmp' is the right name for this? This is not a part
>> of net-snmp project...
> 
> Just like perl* are not part of perl project, php-* and python-*, too.

perl, php, python, java etc. are names of programming languages (i.e.
sth like generic names), net-snmp is only a tool.

-- 
Tomasz Pala <gotar at pld-linux.org>


From zbyniu at geocarbon.pl  Tue May 25 14:36:18 2010
From: zbyniu at geocarbon.pl (Zbyniu Krzystolik)
Date: Tue, 25 May 2010 14:36:18 +0200
Subject: packages: ntp/ntp.spec - net-snmp-ntpd and mibs-ntp
	subpackages, agent seem...
In-Reply-To: <20100525122829.GA21664@polanet.pl>
References: <packages_ntp_ntp.spec.1.137@pld-linux.org>
	<packages_ntp_ntp.spec.1.138@pld-linux.org>
	<20100525115142.GA29829@jajo.eggsoft>
	<201005251406.02272.arekm@maven.pl>
	<20100525122829.GA21664@polanet.pl>
Message-ID: <20100525123618.GM15289@destrukcja.pl>

Tomasz Pala napisa?(a):
> On Tue, May 25, 2010 at 14:06:01 +0200, Arkadiusz Miskiewicz wrote:
> 
> >> > - net-snmp-ntpd and mibs-ntp subpackages, agent seems working
> >> 
> >> Are you sure 'net-snmp' is the right name for this? This is not a part
> >> of net-snmp project...
> > 
> > Just like perl* are not part of perl project, php-* and python-*, too.
> 
> perl, php, python, java etc. are names of programming languages (i.e.
> sth like generic names), net-snmp is only a tool.

openldap-schema-* are in fact general LDAP schemas.

Zbyniu
-- 
%% Absolutely nothing we trust %%


From arekm at maven.pl  Tue May 25 14:52:51 2010
From: arekm at maven.pl (Arkadiusz Miskiewicz)
Date: Tue, 25 May 2010 14:52:51 +0200
Subject: packages: ntp/ntp.spec - net-snmp-ntpd and mibs-ntp subpackages,
	agent seem...
In-Reply-To: <20100525122829.GA21664@polanet.pl>
References: <packages_ntp_ntp.spec.1.137@pld-linux.org>
	<201005251406.02272.arekm@maven.pl>
	<20100525122829.GA21664@polanet.pl>
Message-ID: <201005251452.51891.arekm@maven.pl>

On Tuesday 25 of May 2010, Tomasz Pala wrote:
> On Tue, May 25, 2010 at 14:06:01 +0200, Arkadiusz Miskiewicz wrote:
> >> > - net-snmp-ntpd and mibs-ntp subpackages, agent seems working
> >> 
> >> Are you sure 'net-snmp' is the right name for this? This is not a part
> >> of net-snmp project...
> > 
> > Just like perl* are not part of perl project, php-* and python-*, too.
> 
> perl, php, python, java etc. are names of programming languages (i.e.
> sth like generic names), net-snmp is only a tool.

So? The first few are groupping packages by language and the other by 
application.

net-snmp-ntpd is meant to be used by net-snmp.

-- 
Arkadiusz Mi?kiewicz        PLD/Linux Team
arekm / maven.pl            http://ftp.pld-linux.org/


From gotar at polanet.pl  Tue May 25 15:08:21 2010
From: gotar at polanet.pl (Tomasz Pala)
Date: Tue, 25 May 2010 15:08:21 +0200
Subject: packages: ntp/ntp.spec - net-snmp-ntpd and mibs-ntp subpackages,
	agent seem...
In-Reply-To: <201005251452.51891.arekm@maven.pl>
References: <packages_ntp_ntp.spec.1.137@pld-linux.org>
	<201005251406.02272.arekm@maven.pl>
	<20100525122829.GA21664@polanet.pl>
	<201005251452.51891.arekm@maven.pl>
Message-ID: <20100525130821.GA1363@polanet.pl>

On Tue, May 25, 2010 at 14:52:51 +0200, Arkadiusz Miskiewicz wrote:

>> perl, php, python, java etc. are names of programming languages (i.e.
>> sth like generic names), net-snmp is only a tool.
> 
> So? The first few are groupping packages by language and the other by 
> application.

What 'other'?

> net-snmp-ntpd is meant to be used by net-snmp.

'By' or did you mean 'via' or 'within'? Anyway I can't see any
piece of documentation indicating this is net-snmp specific.

-- 
Tomasz Pala <gotar at pld-linux.org>


From gotar at polanet.pl  Tue May 25 15:09:18 2010
From: gotar at polanet.pl (Tomasz Pala)
Date: Tue, 25 May 2010 15:09:18 +0200
Subject: packages: ntp/ntp.spec - net-snmp-ntpd and mibs-ntp subpackages,
	agent seem...
In-Reply-To: <20100525123618.GM15289@destrukcja.pl>
References: <packages_ntp_ntp.spec.1.137@pld-linux.org>
	<packages_ntp_ntp.spec.1.138@pld-linux.org>
	<20100525115142.GA29829@jajo.eggsoft>
	<201005251406.02272.arekm@maven.pl>
	<20100525122829.GA21664@polanet.pl>
	<20100525123618.GM15289@destrukcja.pl>
Message-ID: <20100525130918.GB1363@polanet.pl>

On Tue, May 25, 2010 at 14:36:18 +0200, Zbyniu Krzystolik wrote:

>> perl, php, python, java etc. are names of programming languages (i.e.
>> sth like generic names), net-snmp is only a tool.
> 
> openldap-schema-* are in fact general LDAP schemas.

So they should be renamed to ldap-schema-*.

-- 
Tomasz Pala <gotar at pld-linux.org>


From baggins at sith.mimuw.edu.pl  Tue May 25 15:15:18 2010
From: baggins at sith.mimuw.edu.pl (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Tue, 25 May 2010 15:15:18 +0200
Subject: packages: ntp/ntp.spec - net-snmp-ntpd and mibs-ntp
	subpackages, agent seem...
In-Reply-To: <20100525130918.GB1363@polanet.pl>
References: <packages_ntp_ntp.spec.1.137@pld-linux.org>
	<packages_ntp_ntp.spec.1.138@pld-linux.org>
	<20100525115142.GA29829@jajo.eggsoft>
	<201005251406.02272.arekm@maven.pl>
	<20100525122829.GA21664@polanet.pl>
	<20100525123618.GM15289@destrukcja.pl>
	<20100525130918.GB1363@polanet.pl>
Message-ID: <20100525131518.GF15173@sith.mimuw.edu.pl>

On Tue, 25 May 2010, Tomasz Pala wrote:

> On Tue, May 25, 2010 at 14:36:18 +0200, Zbyniu Krzystolik wrote:
> 
> >> perl, php, python, java etc. are names of programming languages (i.e.
> >> sth like generic names), net-snmp is only a tool.
> > 
> > openldap-schema-* are in fact general LDAP schemas.
> 
> So they should be renamed to ldap-schema-*.

Provide a working replacement for openldap in distro first.

-- 
Jan R?korajski            |  ALL SUSPECTS ARE GUILTY. PERIOD!
baggins<at>mimuw.edu.pl   |  OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY?
BOFH, MANIAC              |                   -- TROOPS by Kevin Rubio


From arekm at maven.pl  Tue May 25 15:15:44 2010
From: arekm at maven.pl (Arkadiusz Miskiewicz)
Date: Tue, 25 May 2010 15:15:44 +0200
Subject: packages: ntp/ntp.spec - net-snmp-ntpd and mibs-ntp subpackages,
	agent seem...
In-Reply-To: <20100525130821.GA1363@polanet.pl>
References: <packages_ntp_ntp.spec.1.137@pld-linux.org>
	<201005251452.51891.arekm@maven.pl>
	<20100525130821.GA1363@polanet.pl>
Message-ID: <201005251515.45479.arekm@maven.pl>

On Tuesday 25 of May 2010, Tomasz Pala wrote:
> On Tue, May 25, 2010 at 14:52:51 +0200, Arkadiusz Miskiewicz wrote:
> >> perl, php, python, java etc. are names of programming languages (i.e.
> >> sth like generic names), net-snmp is only a tool.
> > 
> > So? The first few are groupping packages by language and the other by
> > application.
> 
> What 'other'?

net-snmp*

> 
> > net-snmp-ntpd is meant to be used by net-snmp.
> 
> 'By' or did you mean 'via' or 'within'? Anyway I can't see any
> piece of documentation indicating this is net-snmp specific.

ntp*.tar.gz/ntpsnmpd/README

meant for net-snmp. If can be used with other snmp agents of whatever - great.

-- 
Arkadiusz Mi?kiewicz        PLD/Linux Team
arekm / maven.pl            http://ftp.pld-linux.org/


From baggins at sith.mimuw.edu.pl  Tue May 25 15:16:51 2010
From: baggins at sith.mimuw.edu.pl (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Tue, 25 May 2010 15:16:51 +0200
Subject: packages: ntp/ntp.spec - net-snmp-ntpd and mibs-ntp
	subpackages, agent seem...
In-Reply-To: <20100525130821.GA1363@polanet.pl>
References: <packages_ntp_ntp.spec.1.137@pld-linux.org>
	<201005251406.02272.arekm@maven.pl>
	<20100525122829.GA21664@polanet.pl>
	<201005251452.51891.arekm@maven.pl>
	<20100525130821.GA1363@polanet.pl>
Message-ID: <20100525131651.GG15173@sith.mimuw.edu.pl>

On Tue, 25 May 2010, Tomasz Pala wrote:

> On Tue, May 25, 2010 at 14:52:51 +0200, Arkadiusz Miskiewicz wrote:
> 
> >> perl, php, python, java etc. are names of programming languages (i.e.
> >> sth like generic names), net-snmp is only a tool.
> > 
> > So? The first few are groupping packages by language and the other by 
> > application.
> 
> What 'other'?
> 
> > net-snmp-ntpd is meant to be used by net-snmp.
> 
> 'By' or did you mean 'via' or 'within'? Anyway I can't see any
> piece of documentation indicating this is net-snmp specific.

Same argument as for ldap schemas - do we have any SNMP other than
net-snmp? No? So what's the problem?

-- 
Jan R?korajski            |  ALL SUSPECTS ARE GUILTY. PERIOD!
baggins<at>mimuw.edu.pl   |  OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY?
BOFH, MANIAC              |                   -- TROOPS by Kevin Rubio