From patrys at pld-linux.org  Tue Jul  1 10:23:23 2008
From: patrys at pld-linux.org (Patryk Zawadzki)
Date: Tue, 1 Jul 2008 10:23:23 +0200
Subject: SPECS (DEVEL): shared-mime-info.spec - proper glib2 deps - moved
	to DEVEL
In-Reply-To: <20080630194859.ef98c93c.freetz@gmx.net>
References: <SPECS_shared_mime_info.spec.1.51@pld-linux.org>
	<SPECS_shared_mime_info.spec.1.51.2.1@pld-linux.org>
	<20080630194859.ef98c93c.freetz@gmx.net>
Message-ID: <89b6ba3a0807010123y4a592308m792d0e87b6335ef6@mail.gmail.com>

On Mon, Jun 30, 2008 at 7:48 PM, Fryderyk Dziarmagowski <freetz at gmx.net> wrote:
> On Mon, 30 Jun 2008 10:28:30 +0200
> patrys <patrys at pld-linux.org> wrote:
>
>> Author: patrys                       Date: Mon Jun 30 08:28:30 2008
>> GMT Module: SPECS                         Tag: DEVEL
>> ---- Log message:
>> - proper glib2 deps
> [...]
>> +Requires:    glib2 >= 1:2.17.2
> What is the cause of this change?

It was discussed several times on GNOME mailing lists - several
packages compiled with old glib are known to fail with this version of
shared-mime-info. See bugs in Fedora, Debian and Gentoo (no direct
links at hand).

-- 
Patryk Zawadzki
PLD Linux Distribution


From freetz at gmx.net  Tue Jul  1 17:52:25 2008
From: freetz at gmx.net (Fryderyk Dziarmagowski)
Date: Tue, 1 Jul 2008 17:52:25 +0200
Subject: SPECS (DEVEL): shared-mime-info.spec - proper glib2 deps -
	moved to DEVEL
In-Reply-To: <89b6ba3a0807010123y4a592308m792d0e87b6335ef6@mail.gmail.com>
References: <SPECS_shared_mime_info.spec.1.51@pld-linux.org>
	<SPECS_shared_mime_info.spec.1.51.2.1@pld-linux.org>
	<20080630194859.ef98c93c.freetz@gmx.net>
	<89b6ba3a0807010123y4a592308m792d0e87b6335ef6@mail.gmail.com>
Message-ID: <20080701175225.c079ed77.freetz@gmx.net>

On Tue, 1 Jul 2008 10:23:23 +0200
"Patryk Zawadzki" <patrys at pld-linux.org> wrote:

> On Mon, Jun 30, 2008 at 7:48 PM, Fryderyk Dziarmagowski
> <freetz at gmx.net> wrote:
> > On Mon, 30 Jun 2008 10:28:30 +0200
> > patrys <patrys at pld-linux.org> wrote:
> >
> >> Author: patrys                       Date: Mon Jun 30 08:28:30 2008
> >> GMT Module: SPECS                         Tag: DEVEL
> >> ---- Log message:
> >> - proper glib2 deps
> > [...]
> >> +Requires:    glib2 >= 1:2.17.2
> > What is the cause of this change?
> 
> It was discussed several times on GNOME mailing lists - several
> packages compiled with old glib are known to fail with this version of
> shared-mime-info. See bugs in Fedora, Debian and Gentoo (no direct
> links at hand).

Rumors on GNOME ml should be a source of PLD development.
shared-mime-info 0.40 is not present in debian repo, Fedora got no bug
reports about this, Gentoo bug says "rebuild your mime.cache" because
of format change between 0.30 and 0.40.

-- 
Fryderyk Dziarmagowski


From adamg at biomerieux.pl  Thu Jul  3 10:10:39 2008
From: adamg at biomerieux.pl (Adam =?utf-8?B?R2/FgsSZYmlvd3NraQ==?=)
Date: Thu, 3 Jul 2008 10:10:39 +0200
Subject: dropin ?
In-Reply-To: <200806300007.02571.arekm@maven.pl>
References: <20080629215342.GA6770@mysza.eu.org>
	<200806300007.02571.arekm@maven.pl>
Message-ID: <20080703081039.GA913@mysza.eu.org>

On Mon, Jun 30, 2008 at 12:07:02AM +0200, Arkadiusz Miskiewicz wrote:
> Probably tmpwatch cleaned up /tmp where symlinks used by dropin were created.

works now.

-- 
 http://www.mysza.eu.org/ | Everybody needs someone sure, someone true,
   PLD Linux developer    | Everybody needs some solid rock, I know I do.


From arekm at maven.pl  Thu Jul  3 10:17:43 2008
From: arekm at maven.pl (Arkadiusz Miskiewicz)
Date: Thu, 3 Jul 2008 10:17:43 +0200
Subject: dropin ?
In-Reply-To: <20080703081039.GA913@mysza.eu.org>
References: <20080629215342.GA6770@mysza.eu.org>
	<200806300007.02571.arekm@maven.pl>
	<20080703081039.GA913@mysza.eu.org>
Message-ID: <200807031017.43708.arekm@maven.pl>

On Thursday 03 July 2008, Adam Go??biowski wrote:
> On Mon, Jun 30, 2008 at 12:07:02AM +0200, Arkadiusz Miskiewicz wrote:
> > Probably tmpwatch cleaned up /tmp where symlinks used by dropin were
> > created.
>
> works now.

Yes, I fixed it few days ago (and moved dropin queue from /tmp/dropin 
to /var/lib/dropin). Also fixed fetchsrc_request.

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


From zbyniu at geocarbon.pl  Thu Jul  3 12:12:46 2008
From: zbyniu at geocarbon.pl (Zbyniu Krzystolik)
Date: Thu, 3 Jul 2008 12:12:46 +0200
Subject: SPECS (LINUX_2_6): kernel.spec - use underscore in kernel
	release for KABI ...
In-Reply-To: <SPECS_kernel.spec.1.441.2.1934@pld-linux.org>
References: <SPECS_kernel.spec.1.441.2.1933@pld-linux.org>
	<SPECS_kernel.spec.1.441.2.1934@pld-linux.org>
Message-ID: <20080703101246.GD9126@geocarbon.pl>

Mniej wiecej Thu, Jul 03, 2008 at 11:17:20AM +0200, zainteresowany glen rzekl:
> Author: glen                         Date: Thu Jul  3 09:17:20 2008 GMT
> Module: SPECS                         Tag: LINUX_2_6
> ---- Log message:
> - use underscore in kernel release for KABI to be a lit less misleading

> -%define		kernel_release %{version}%{?_alt_kernel:%{_alt_kernel}}-%{_localversion}
> +%define		kernel_release %{version}%{?_alt_kernel:%{_alt_kernel}}_%{KABI}

What for? You are changing package name that exist since always and it
is "less misleading"?

Zbyniu
-- 
%% Absolutely nothing we trust %%


From gotar at polanet.pl  Thu Jul  3 12:51:31 2008
From: gotar at polanet.pl (Tomasz Pala)
Date: Thu, 3 Jul 2008 12:51:31 +0200
Subject: rpmbuild and gawk
Message-ID: <20080703105131.GA18396@pepin.polanet.pl>

Hi,

while building udns.spec (just commited) I've encountered following
errors at the end of %install section. Upgrading gawk from 3.1.3-3 to
3.1.5-2 fixed problem, but it means there's some R: missing. I've got
also mawk-1.3.3-30 installed with /bin/awk -> mawk and I have no idea
why having older gawk caused the problem at all.

+ install udns.3 /tmp/udns-0.0.9-root-gotar/usr/share/man/man3
+ __spec_install_post_strip
Usage: awk [POSIX or GNU style options] -f progfile [--] file ...
Usage: awk [POSIX or GNU style options] [--] 'program' file ...
POSIX options:          GNU long options:
        -f progfile             --file=progfile
        -F fs                   --field-separator=fs
        -v var=val              --assign=var=val
        -m[fr] val
        -W compat               --compat
        -W copyleft             --copyleft
        -W copyright            --copyright
        -W dump-variables[=file]        --dump-variables[=file]
        -W gen-po               --gen-po
        -W help                 --help
        -W lint[=fatal]         --lint[=fatal]
        -W lint-old             --lint-old
        -W non-decimal-data     --non-decimal-data
        -W profile[=file]       --profile[=file]
        -W posix                --posix
        -W re-interval          --re-interval
        -W source=program-text  --source=program-text
        -W traditional          --traditional
        -W usage                --usage
        -W version              --version

To report bugs, see node `Bugs' in `gawk.info', which is
section `Reporting Problems and Bugs' in the printed version.

gawk is a pattern scanning and processing language.
By default it reads standard input and writes standard output.

Examples:
        gawk '{ sum += $1 }; END { print sum }' file
        gawk -F: '{ print $1 }' /etc/passwd
error: Bad exit status from /var/tmp/rpm-tmp.93164 (%install)


RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.93164 (%install)

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


From gotar at polanet.pl  Thu Jul  3 13:04:30 2008
From: gotar at polanet.pl (Tomasz Pala)
Date: Thu, 3 Jul 2008 13:04:30 +0200
Subject: rpmbuild and gawk
In-Reply-To: <20080703105131.GA18396@pepin.polanet.pl>
References: <20080703105131.GA18396@pepin.polanet.pl>
Message-ID: <20080703110430.GA29870@pepin.polanet.pl>

On Thu, Jul 03, 2008 at 12:51:31 +0200, Tomasz Pala wrote:

> while building udns.spec (just commited) I've encountered following
> errors at the end of %install section. Upgrading gawk from 3.1.3-3 to
> 3.1.5-2 fixed problem, but it means there's some R: missing. I've got
> also mawk-1.3.3-30 installed with /bin/awk -> mawk and I have no idea
> why having older gawk caused the problem at all.

Well, there was /usr/bin/awk -> gawk so there should be C: gawk < x.y.z
somewhere in rpm-build-macros.

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


From glen at delfi.ee  Thu Jul  3 13:46:53 2008
From: glen at delfi.ee (Elan =?iso-8859-1?q?Ruusam=E4e?=)
Date: Thu, 3 Jul 2008 14:46:53 +0300
Subject: SPECS (LINUX_2_6): kernel.spec - use underscore in kernel release
	for KABI ...
In-Reply-To: <20080703101246.GD9126@geocarbon.pl>
References: <SPECS_kernel.spec.1.441.2.1933@pld-linux.org>
	<SPECS_kernel.spec.1.441.2.1934@pld-linux.org>
	<20080703101246.GD9126@geocarbon.pl>
Message-ID: <200807031446.53900.glen@delfi.ee>

On Thursday 03 July 2008 13:12, Zbyniu Krzystolik wrote:
> Mniej wiecej Thu, Jul 03, 2008 at 11:17:20AM +0200, zainteresowany glen 
rzekl:
> > Author: glen                         Date: Thu Jul  3 09:17:20 2008 GMT
> > Module: SPECS                         Tag: LINUX_2_6
> > ---- Log message:
> > - use underscore in kernel release for KABI to be a lit less misleading
> >
> > -%define		kernel_release
> > %{version}%{?_alt_kernel:%{_alt_kernel}}-%{_localversion}
> > +%define		kernel_release %{version}%{?_alt_kernel:%{_alt_kernel}}_%{KABI}
>
> What for? You are changing package name that exist since always and it
> is "less misleading"?
package name???

the change is there as %{kabi} != %{release} most of the time, and you've used 
to that %{release} is last part in uname -r after dash. the change was 
discussed and approved by arekm (th rm).

> Zbyniu

-- 
glen


From gotar at polanet.pl  Thu Jul  3 13:54:07 2008
From: gotar at polanet.pl (Tomasz Pala)
Date: Thu, 3 Jul 2008 13:54:07 +0200
Subject: jabberd resolver component
Message-ID: <20080703115407.GA18768@pepin.polanet.pl>

* 2.1.24 to 2.2.0 upgrade:

Resolver is now built in S2S component, so you need to add <lookup/> section
to your s2s.xml config. Then remove resolver component from your configuration.



As I have no running jabberd2 for now I don't know how this upgrade
should be handled by rpm (trigger changing configuration or something?).
Thus I leave 0.1 release.

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


From glen at pld-linux.org  Thu Jul  3 17:25:02 2008
From: glen at pld-linux.org (Elan =?iso-8859-1?q?Ruusam=E4e?=)
Date: Thu, 3 Jul 2008 18:25:02 +0300
Subject: SPECS: crossmingw64-gcc.spec - workaround 'argument list to long',
	remeve -...
In-Reply-To: <SPECS_crossmingw64_gcc.spec.1.7@pld-linux.org>
References: <SPECS_crossmingw64_gcc.spec.1.6@pld-linux.org>
	<SPECS_crossmingw64_gcc.spec.1.7@pld-linux.org>
Message-ID: <200807031825.02979.glen@pld-linux.org>

On Thursday 03 July 2008 18:13, pluto wrote:
> -mv $RPM_BUILD_ROOT%{_prefix}/x86_64-pc-mingw32/lib/* \
> -???????$RPM_BUILD_ROOT%{arch}/lib
> +find $RPM_BUILD_ROOT%{_prefix}/x86_64-pc-mingw32/lib -type f \
> +???????-exec mv "{}" "$RPM_BUILD_ROOT%{arch}/lib" ";"
> ?

that's slow (exeve mv for each file), try shortening the path:

(cd $RPM_BUILD_ROOT%{_prefix}/x86_64-pc-mingw32/lib/*; \
mv * $RPM_BUILD_ROOT%{arch}/lib)

mv [a-k]*
mv [l-z]*

could be tried next (C locale is a MUST! for char ranges)

-- 
glen


From zbyniu at geocarbon.pl  Fri Jul  4 00:13:23 2008
From: zbyniu at geocarbon.pl (Zbyniu Krzystolik)
Date: Fri, 4 Jul 2008 00:13:23 +0200
Subject: SPECS (LINUX_2_6): kernel.spec - use underscore in kernel
	release for KABI ...
In-Reply-To: <200807031446.53900.glen@delfi.ee>
References: <SPECS_kernel.spec.1.441.2.1933@pld-linux.org>
	<SPECS_kernel.spec.1.441.2.1934@pld-linux.org>
	<20080703101246.GD9126@geocarbon.pl>
	<200807031446.53900.glen@delfi.ee>
Message-ID: <20080703221323.GH9126@geocarbon.pl>

Mniej wiecej Thu, Jul 03, 2008 at 02:46:53PM +0300, zainteresowany Elan Ruusam?e rzekl:
> On Thursday 03 July 2008 13:12, Zbyniu Krzystolik wrote:
> > Mniej wiecej Thu, Jul 03, 2008 at 11:17:20AM +0200, zainteresowany glen 
> rzekl:
> > > Author: glen                         Date: Thu Jul  3 09:17:20 2008 GMT
> > > Module: SPECS                         Tag: LINUX_2_6
> > > ---- Log message:
> > > - use underscore in kernel release for KABI to be a lit less misleading
> > >
> > > -%define		kernel_release
> > > %{version}%{?_alt_kernel:%{_alt_kernel}}-%{_localversion}
> > > +%define		kernel_release %{version}%{?_alt_kernel:%{_alt_kernel}}_%{KABI}
> >
> > What for? You are changing package name that exist since always and it
> > is "less misleading"?

> package name???                                                                                  

Image name of course.

> the change is there as %{kabi} != %{release} most of the time,                                   

Why not? new kernel vsersions are in every week so kabi should be set to
1 every week.

> and you've used to that %{release} is last part in uname -r after
> dash.                          

ok, and let it be dash not underscore.

Zbyniu
-- 
%% Absolutely nothing we trust %%


From glen at pld-linux.org  Wed Jul  9 00:56:06 2008
From: glen at pld-linux.org (Elan =?iso-8859-1?q?Ruusam=E4e?=)
Date: Wed, 9 Jul 2008 01:56:06 +0300
Subject: SPECS: kvm.spec - don't require external qemu, doesn't make sense.
In-Reply-To: <SPECS_kvm.spec.1.41@pld-linux.org>
References: <SPECS_kvm.spec.1.40@pld-linux.org>
	<SPECS_kvm.spec.1.41@pld-linux.org>
Message-ID: <200807090156.07887.glen@pld-linux.org>

On Wednesday 09 July 2008 00:41, blues wrote:
> Author: blues                        Date: Tue Jul  8 21:41:38 2008 GMT
> Module: SPECS                         Tag: HEAD
> ---- Log message:
> - don't require external qemu, doesn't make sense.
>
> ---- Files affected:
> SPECS:
>    kvm.spec (1.40 -> 1.41)
>
> ---- Diffs:
>
> ================================================================
> Index: SPECS/kvm.spec
> diff -u SPECS/kvm.spec:1.40 SPECS/kvm.spec:1.41
> --- SPECS/kvm.spec:1.40	Tue Jun 24 13:26:41 2008
> +++ SPECS/kvm.spec	Tue Jul  8 23:41:32 2008
> @@ -1,6 +1,5 @@
>  # $Revision$, $Date$
>  # TODO:
> -# - udev is optional, so separate udev stuff from kernel module
>  # - doesn't build on ppc, fix this if possible
>  #
>  # Conditional build:
> @@ -40,12 +39,15 @@
>  BuildRequires:	SDL-devel
>  BuildRequires:	alsa-lib-devel
>  BuildRequires:	zlib-devel
> -Requires:	qemu
> +Conflicts:	qemu
>  %endif
>  # ppc broken?
>  ExclusiveArch:	%{ix86} %{x8664} ia64
>  BuildRoot:	%{tmpdir}/%{name}-%{version}-root-%(id -u -n)
>
> +# some SPARC boot image in ELF format
> +%define         _noautostrip    .*%{_datadir}/qemu/openbios-sparc32
> +
>  %description
>  KVM (for Kernel-based Virtual Machine) is a full virtualization
>  solution for Linux on x86 hardware. It consists of a loadable kernel
> @@ -129,8 +131,8 @@
>  	DESTDIR=$RPM_BUILD_ROOT
>
>  # removing files which are provided by required qemu package
> -rm -rf $RPM_BUILD_ROOT%{_datadir}/qemu $RPM_BUILD_ROOT%{_mandir}
> $RPM_BUILD_ROOT%{_docdir} -rm -f $RPM_BUILD_ROOT%{_bindir}/qemu-img
> +#rm -rf $RPM_BUILD_ROOT%{_datadir}/qemu $RPM_BUILD_ROOT%{_mandir}
> $RPM_BUILD_ROOT%{_docdir} +#rm -f $RPM_BUILD_ROOT%{_bindir}/qemu-img
>
>  # changing binary name to avoid conflict with qemu
>  mv -f $RPM_BUILD_ROOT%{_bindir}/qemu-system-x86_64
> $RPM_BUILD_ROOT%{_bindir}/%{pname} @@ -161,7 +163,10 @@
>  %if %{with userspace}
>  %files
>  %defattr(644,root,root,755)
> -%attr(755,root,root) %{_bindir}/kvm*
> +%attr(755,root,root) %{_bindir}/*
> +%{_datadir}/qemu
> +%{_mandir}/man1/qemu.1*
> +%{_mandir}/man1/qemu-img.1*
now i can't have kvm and qemu installed on same system ... unreasonable 
limitation.

>  %files udev
>  %defattr(644,root,root,755)
> @@ -180,6 +185,9 @@
>  All persons listed below can be reached at <cvs_login>@pld-linux.org
>
>  $Log$
> +Revision 1.41  2008/07/08 21:41:32  blues
> +- don't require external qemu, doesn't make sense.
why so? the /usr/share part is common, binary from kvm is just patched.

-- 
glen


From z at grabina.waw.pl  Thu Jul 10 10:57:48 2008
From: z at grabina.waw.pl (=?utf-8?q?Pawe=C5=82_Zuzelski?=)
Date: Thu, 10 Jul 2008 10:57:48 +0200
Subject: SPECS: xmlbeansxx.spec - adapter, pldize
In-Reply-To: <SPECS_xmlbeansxx.spec.1.2@pld-linux.org>
References: <SPECS_xmlbeansxx.spec.1.1@pld-linux.org>
	<SPECS_xmlbeansxx.spec.1.2@pld-linux.org>
Message-ID: <200807101057.48860.z@grabina.waw.pl>

On Thursday 10 of July 2008 00:38:12 glen wrote:
> -%{_bindir}/scompxx
> -%{_bindir}/xmlbeansxx-gen
> -%{_bindir}/xmlbeansxx-geninclude
> -%{_bindir}/xmlbeansxx-split
> +%attr(755,root,root) %{_bindir}/scompxx
> +%attr(755,root,root) %{_bindir}/xmlbeansxx-gen
> +%attr(755,root,root) %{_bindir}/xmlbeansxx-geninclude
> +%attr(755,root,root) %{_bindir}/xmlbeansxx-split

These files are symlinks. Does %attr make sense on them?

BTW thx for fixing source URL.

-- 
Regards,
Pawe? Zuzelski


From glen at pld-linux.org  Thu Jul 10 20:16:16 2008
From: glen at pld-linux.org (Elan =?utf-8?q?Ruusam=C3=A4e?=)
Date: Thu, 10 Jul 2008 21:16:16 +0300
Subject: SPECS: scsiutils.spec - scsidev moved to separate package
	(Suggested) - R: ...
In-Reply-To: <SPECS_scsiutils.spec.1.32@pld-linux.org>
References: <SPECS_scsiutils.spec.1.31@pld-linux.org>
	<SPECS_scsiutils.spec.1.32@pld-linux.org>
Message-ID: <200807102116.17491.glen@pld-linux.org>

On Thursday 10 July 2008 20:47:44 qboosh wrote:
> ?$Log$
> +Revision 1.32 ?2008/07/10 17:47:39 ?qboosh
> +- scsidev moved to separate package (Suggested)
> +- R: sg3_utils (for rescan-scsi-bus.sh)
> +

rescan-scsi-bus.sh has own spec: rescan-scsi-bus.spec

-- 
glen


From qboosh at pld-linux.org  Thu Jul 10 20:20:44 2008
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Thu, 10 Jul 2008 20:20:44 +0200
Subject: SPECS: scsiutils.spec - scsidev moved to separate package
	(Suggested) - R: ...
In-Reply-To: <200807102116.17491.glen@pld-linux.org>
References: <SPECS_scsiutils.spec.1.31@pld-linux.org>
	<SPECS_scsiutils.spec.1.32@pld-linux.org>
	<200807102116.17491.glen@pld-linux.org>
Message-ID: <20080710182044.GA9434@stranger.qboosh.pl>

On Thu, Jul 10, 2008 at 09:16:16PM +0300, Elan Ruusam?e wrote:
> On Thursday 10 July 2008 20:47:44 qboosh wrote:
> > ?$Log$
> > +Revision 1.32 ?2008/07/10 17:47:39 ?qboosh
> > +- scsidev moved to separate package (Suggested)
> > +- R: sg3_utils (for rescan-scsi-bus.sh)
> > +
> 
> rescan-scsi-bus.sh has own spec: rescan-scsi-bus.spec

Fine, so I don't need to create it ;)
And I'm killing scsiutils.spec right now.


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


From glen at pld-linux.org  Fri Jul 11 01:34:44 2008
From: glen at pld-linux.org (Elan =?iso-8859-1?q?Ruusam=E4e?=)
Date: Fri, 11 Jul 2008 02:34:44 +0300
Subject: SPECS: rescan-scsi-bus.spec - better Group (Applications/System)
	- R: sg3_u...
In-Reply-To: <SPECS_rescan_scsi_bus.spec.1.6@pld-linux.org>
References: <SPECS_rescan_scsi_bus.spec.1.5@pld-linux.org>
	<SPECS_rescan_scsi_bus.spec.1.6@pld-linux.org>
Message-ID: <200807110234.46116.glen@pld-linux.org>

On Thursday 10 July 2008 21:35, qboosh wrote:
> ?$Log$
> +Revision 1.6 ?2008/07/10 18:35:09 ?qboosh
> +- better Group (Applications/System)
> +- R: sg3_utils (sg_* commands are used)
> +

S: perhaps? as i've used the script on lpfc system without needing the 
sg3_utils tools.

-- 
glen


From mmazur at kernel.pl  Wed Jul 16 12:43:25 2008
From: mmazur at kernel.pl (Mariusz Mazur)
Date: Wed, 16 Jul 2008 12:43:25 +0200
Subject: [ANNOUNCEMENT] Bugzilla >/dev/null, switching to launchpad.net
Message-ID: <200807161243.25745.mmazur@kernel.pl>

From now on bugs.pld-linux.org redirects to 
https://bugs.launchpad.net/pld-linux. Old bugzilla is available under, well, 
oldbugzilla.pld-linux.org with the only modification being that the 'add new 
bug' form redirects to the appropriate launchpad form, meaning it's not 
possible to add new bugs to the old bugzilla.

Plan is for the migration to be a natural process without any forced bug db 
migration. Bugs already inside bugzilla are to be resolved there, unless 
they're some kind of uber important long-term bugs in which case ppl are free 
to manually close them in bugzilla and reopen in launchpad (with a url 
pointing to bugzilla where appropriate). For ppl still working on some 
already opened bugzilla bugs, should there be any problems, describe them 
inside this email thread.

Rationale:
Launchpad was chosen because (a) we don't have to maintain it, (b) we don't 
have to host it (backups, whatever), (c) we don't have to develop it and (d) 
it has some nice feature for upstream integration.

Oh, just to make one thing clear -- launchpad has been in use by some 
developers for some time now and all of the current RM's either are for this 
switch or don't care either way. I really hope there are no bugzilla zealots 
or launchpad haters :)


-- 
Judge others by their intentions and yourself by your results.
                                                                 Guy Kawasaki
Education is an admirable thing, but it is well to remember from
time to time that nothing that is worth knowing can be taught.
                                                                  Oscar Wilde


From adamg at biomerieux.pl  Wed Jul 16 13:03:07 2008
From: adamg at biomerieux.pl (Adam =?utf-8?B?R2/FgsSZYmlvd3NraQ==?=)
Date: Wed, 16 Jul 2008 13:03:07 +0200
Subject: [ANNOUNCEMENT] Bugzilla >/dev/null, switching to launchpad.net
In-Reply-To: <200807161243.25745.mmazur@kernel.pl>
References: <200807161243.25745.mmazur@kernel.pl>
Message-ID: <20080716110307.GB26506@mysza.eu.org>

On Wed, Jul 16, 2008 at 12:43:25PM +0200, Mariusz Mazur wrote:
> Rationale:
> Launchpad was chosen because (a) we don't have to maintain it, (b) we don't 
> have to host it (backups, whatever), (c) we don't have to develop it and (d) 
> it has some nice feature for upstream integration.

hmm, as to a) and b) -- was it really so time consuming? 
c) - we didn't do any development with bugzilla either,
d) like? (I'm curious)

> Oh, just to make one thing clear -- launchpad has been in use by some 
> developers for some time now and all of the current RM's either are for this 
> switch or don't care either way. I really hope there are no bugzilla zealots 
> or launchpad haters :)

Bugzilla looked a little bit simpler to me (design, not the forms
itself). The page was also rendered faster.

It looks like launchpad doesn't send mail reports to bugs at pld-linux.org,
please fix this.

-- 
 http://www.mysza.eu.org/ | Everybody needs someone sure, someone true,
   PLD Linux developer    | Everybody needs some solid rock, I know I do.


From patrys at pld-linux.org  Wed Jul 16 13:19:13 2008
From: patrys at pld-linux.org (Patryk Zawadzki)
Date: Wed, 16 Jul 2008 13:19:13 +0200
Subject: [ANNOUNCEMENT] Bugzilla >/dev/null, switching to launchpad.net
In-Reply-To: <20080716110307.GB26506@mysza.eu.org>
References: <200807161243.25745.mmazur@kernel.pl>
	<20080716110307.GB26506@mysza.eu.org>
Message-ID: <89b6ba3a0807160419x3869062ek90f9c2e5ff7740ea@mail.gmail.com>

On Wed, Jul 16, 2008 at 1:03 PM, Adam Go??biowski <adamg at biomerieux.pl> wrote:
> On Wed, Jul 16, 2008 at 12:43:25PM +0200, Mariusz Mazur wrote:
>> Rationale:
>> Launchpad was chosen because (a) we don't have to maintain it, (b) we don't
>> have to host it (backups, whatever), (c) we don't have to develop it and (d)
>> it has some nice feature for upstream integration.
> hmm, as to a) and b) -- was it really so time consuming?
> c) - we didn't do any development with bugzilla either,

Bugzilla has a pile of shit instead of a nice API. We can either
depend on Ubuntu's effort or write our own tools to allow automated
crash reporting (apport.spec).

> d) like? (I'm curious)

Assigning a single bug to multiple projects/distros.

>> Oh, just to make one thing clear -- launchpad has been in use by some
>> developers for some time now and all of the current RM's either are for this
>> switch or don't care either way. I really hope there are no bugzilla zealots
>> or launchpad haters :)
> Bugzilla looked a little bit simpler to me (design, not the forms
> itself). The page was also rendered faster.

It only took two screens of scrolling to read the initial report :)

> It looks like launchpad doesn't send mail reports to bugs at pld-linux.org,
> please fix this.

Please create an account for bugs at pld-linux.org on launchpad and have
it join the PLD Bugsquad group. I can't do this as I'm not subscribed
to bugs at pld-linux.

-- 
Patryk Zawadzki
PLD Linux Distribution

From mmazur at kernel.pl  Wed Jul 16 13:44:58 2008
From: mmazur at kernel.pl (Mariusz Mazur)
Date: Wed, 16 Jul 2008 13:44:58 +0200
Subject: [ANNOUNCEMENT] Bugzilla >/dev/null, switching to launchpad.net
In-Reply-To: <20080716110307.GB26506@mysza.eu.org>
References: <200807161243.25745.mmazur@kernel.pl>
	<20080716110307.GB26506@mysza.eu.org>
Message-ID: <200807161344.58655.mmazur@kernel.pl>

Dnia ?roda, 16 lipca 2008, Adam Go??biowski napisa?:
> hmm, as to a) and b) -- was it really so time consuming?

No, because once set up, without a good reason (like a fscked up filesystem) 
usually nobody touches those things (point being -- no maintenance effort 
equals no new features).

> c) - we didn't do any development with bugzilla either,

Yup. But now other ppl do it for us. I've just had a look around and this 
thing has some really nice features we could start integrating against.


-- 
Judge others by their intentions and yourself by your results.
                                                                 Guy Kawasaki
Education is an admirable thing, but it is well to remember from
time to time that nothing that is worth knowing can be taught.
                                                                  Oscar Wilde


From patrys at pld-linux.org  Wed Jul 16 15:07:08 2008
From: patrys at pld-linux.org (Patryk Zawadzki)
Date: Wed, 16 Jul 2008 15:07:08 +0200
Subject: Packaging .py files
Message-ID: <89b6ba3a0807160607i694f7b15s95218947936689d9@mail.gmail.com>

Hi,

Following up on a Jabber discussion with arekm I'd like to start
packaging .py files along with their bytecode counterparts. The
reasoning:

1) It's much easier to find bugs in your own code (or the code you're
packaging at the moment) when the libraries are available at hand
(currently I'm forced to do `builder -bp python-foo`).

2) It's much easier to trace faulty applications when you can just
copy the path from a traceback and open the file in vim (yes, yes, or
emacs).

3) We'll no longer need to patch multiple applications that either use
codegen.py (patches for this are all over the place) or use
glob("*.py") to find their plugins.

I'm not planning a mass commit or anything but I'll start packaging
the sources instead of removing them when commiting from now on.

Please no "save the 1k of disk space" arguments.

-- 
Patryk Zawadzki
PLD Linux Distribution


From qboosh at pld-linux.org  Wed Jul 16 18:49:47 2008
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Wed, 16 Jul 2008 18:49:47 +0200
Subject: Packaging .py files
In-Reply-To: <89b6ba3a0807160631t5872f665kb780a792e6291516@mail.gmail.com>
References: <89b6ba3a0807160607i694f7b15s95218947936689d9@mail.gmail.com>
	<200807161517.04664.mateusz@ant.gliwice.pl>
	<89b6ba3a0807160631t5872f665kb780a792e6291516@mail.gmail.com>
Message-ID: <20080716164947.GA8019@stranger.qboosh.pl>

(moving to -en)

On Wed, Jul 16, 2008 at 03:31:41PM +0200, Patryk Zawadzki wrote:
> On Wed, Jul 16, 2008 at 3:17 PM, Mateusz Korniak <mateusz at ant.gliwice.pl> wrote:
> > On Wednesday 16 of July 2008, Patryk Zawadzki wrote:
> >> I'd like to start
> >> packaging .py files along with their bytecode counterparts. The
> >> reasoning:
> >>
> >> 1) It's much easier to find bugs in your own code (...)
> >>
> >> 2) It's much easier to trace faulty applications (...)
> >>
> >> 3) We'll no longer need to patch multiple applications that either use
> >> codegen.py (patches for this are all over the place) or use
> >> glob("*.py") to find their plugins.
> >>
> >> I'm not planning a mass commit or anything but I'll start packaging
> >> the sources instead of removing them when commiting from now on.
> >>
> >> Please no "save the 1k of disk space" arguments.
> >
> > We can pack *.py and *.pyo (instead of *.pyc *.pyo) archiving almost same and
> > having "save the 1k of disk space" ;)
> 
> Yeah, having .pyc files next to their optimized versions would be useless.

That's false, replacing .pyc with .py is very bad idea.

1. .pyo files are used only when python is called with -O option.

2. if module .pyc file is not present, python (called without -O) attempts
to write it - so using some python module with root privileges would
create .pyc files not belonging to any package

And when presenting your idea, use real numbers, not disdained "1k".
I bet it's about 10-20MB on average system (depending on usage of some
GNOME/KDE python applications or python frameworks like Twisted or
Django).


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


From patrys at pld-linux.org  Wed Jul 16 18:57:30 2008
From: patrys at pld-linux.org (Patryk Zawadzki)
Date: Wed, 16 Jul 2008 18:57:30 +0200
Subject: Packaging .py files
In-Reply-To: <20080716164947.GA8019@stranger.qboosh.pl>
References: <89b6ba3a0807160607i694f7b15s95218947936689d9@mail.gmail.com>
	<200807161517.04664.mateusz@ant.gliwice.pl>
	<89b6ba3a0807160631t5872f665kb780a792e6291516@mail.gmail.com>
	<20080716164947.GA8019@stranger.qboosh.pl>
Message-ID: <89b6ba3a0807160957q60e4d29ck6c26ec45973eac5d@mail.gmail.com>

On Wed, Jul 16, 2008 at 6:49 PM, Jakub Bogusz <qboosh at pld-linux.org> wrote:
> (moving to -en)
> On Wed, Jul 16, 2008 at 03:31:41PM +0200, Patryk Zawadzki wrote:
>> On Wed, Jul 16, 2008 at 3:17 PM, Mateusz Korniak <mateusz at ant.gliwice.pl> wrote:
>> > On Wednesday 16 of July 2008, Patryk Zawadzki wrote:
>> >> I'd like to start
>> >> packaging .py files along with their bytecode counterparts. The
>> >> reasoning:
>> >>
>> >> 1) It's much easier to find bugs in your own code (...)
>> >>
>> >> 2) It's much easier to trace faulty applications (...)
>> >>
>> >> 3) We'll no longer need to patch multiple applications that either use
>> >> codegen.py (patches for this are all over the place) or use
>> >> glob("*.py") to find their plugins.
>> >>
>> >> I'm not planning a mass commit or anything but I'll start packaging
>> >> the sources instead of removing them when commiting from now on.
>> >>
>> >> Please no "save the 1k of disk space" arguments.
>> >
>> > We can pack *.py and *.pyo (instead of *.pyc *.pyo) archiving almost same and
>> > having "save the 1k of disk space" ;)
>>
>> Yeah, having .pyc files next to their optimized versions would be useless.
>
> That's false, replacing .pyc with .py is very bad idea.

Then we can/should package them all. I don't want to fix correct code
to look for .pyc files instead of .py (all packages using codegen).

> 1. .pyo files are used only when python is called with -O option.

True, sorry but I'm in zombie state today due to weather changes (no,
coffee does not help).

> 2. if module .pyc file is not present, python (called without -O) attempts
> to write it - so using some python module with root privileges would
> create .pyc files not belonging to any package

Also true.

> And when presenting your idea, use real numbers, not disdained "1k".
> I bet it's about 10-20MB on average system (depending on usage of some
> GNOME/KDE python applications or python frameworks like Twisted or
> Django).

On these systems 10MB is the same as 1k.

-- 
Patryk Zawadzki
PLD Linux Distribution


From tomasz.wittner at gmail.com  Wed Jul 16 20:27:36 2008
From: tomasz.wittner at gmail.com (Tomasz Wittner)
Date: Wed, 16 Jul 2008 20:27:36 +0200
Subject: Packaging .py files
In-Reply-To: <89b6ba3a0807160607i694f7b15s95218947936689d9@mail.gmail.com>
References: <89b6ba3a0807160607i694f7b15s95218947936689d9@mail.gmail.com>
Message-ID: <200807162027.36694.tomasz.wittner@gmail.com>

On Wednesday 16 of July 2008, 15:07, Patryk Zawadzki wrote:
> Hi,
>
> Following up on a Jabber discussion with arekm I'd like to start
> packaging .py files along with their bytecode counterparts. 
Then put them in separate packages, named python-FOO-src or sth like that.
[...]
-- 
Tomasz Wittner


From glen at delfi.ee  Wed Jul 16 20:56:00 2008
From: glen at delfi.ee (Elan =?iso-8859-1?q?Ruusam=E4e?=)
Date: Wed, 16 Jul 2008 21:56:00 +0300
Subject: Packaging .py files
In-Reply-To: <89b6ba3a0807160607i694f7b15s95218947936689d9@mail.gmail.com>
References: <89b6ba3a0807160607i694f7b15s95218947936689d9@mail.gmail.com>
Message-ID: <200807162156.01036.glen@delfi.ee>

On Wednesday 16 July 2008 16:07, Patryk Zawadzki wrote:
> Please no "save the 1k of disk space" arguments.

can the packaging be automated like -debuginfo is right now?

i'd vote for -pysource, -source names :)

-- 
glen


From glen at delfi.ee  Wed Jul 16 21:00:33 2008
From: glen at delfi.ee (Elan =?iso-8859-1?q?Ruusam=E4e?=)
Date: Wed, 16 Jul 2008 22:00:33 +0300
Subject: vim-rt size (was Re: Packaging .py files)
In-Reply-To: <89b6ba3a0807160957q60e4d29ck6c26ec45973eac5d@mail.gmail.com>
References: <89b6ba3a0807160607i694f7b15s95218947936689d9@mail.gmail.com>
	<20080716164947.GA8019@stranger.qboosh.pl>
	<89b6ba3a0807160957q60e4d29ck6c26ec45973eac5d@mail.gmail.com>
Message-ID: <200807162200.33665.glen@delfi.ee>

On Wednesday 16 July 2008 19:57, Patryk Zawadzki wrote:
> On these systems 10MB is the same as 1k.

can vim-rt files be compressed somehow?

i know vim can read .gz files and write them, can it do same for help/ and 
syntax/ files

i'm also thinking perhaps create -doc subpackage.

as i have few systems where /usr is really small and can't be grown . (do not 
ask why), but i like vim, mostly due it's syntax hiliting feature.

-- 
glen


From gotar at polanet.pl  Wed Jul 16 22:07:41 2008
From: gotar at polanet.pl (Tomasz Pala)
Date: Wed, 16 Jul 2008 22:07:41 +0200
Subject: vim-rt size (was Re: Packaging .py files)
In-Reply-To: <200807162200.33665.glen@delfi.ee>
References: <89b6ba3a0807160607i694f7b15s95218947936689d9@mail.gmail.com>
	<20080716164947.GA8019@stranger.qboosh.pl>
	<89b6ba3a0807160957q60e4d29ck6c26ec45973eac5d@mail.gmail.com>
	<200807162200.33665.glen@delfi.ee>
Message-ID: <20080716200741.GA20621@pepin.polanet.pl>

On Wed, Jul 16, 2008 at 22:00:33 +0300, Elan Ruusam?e wrote:

> i'm also thinking perhaps create -doc subpackage.

It's only 5MB...

> as i have few systems where /usr is really small and can't be grown . (do not 
> ask why), but i like vim, mostly due it's syntax hiliting feature.

Use excludedocs Luke.

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


From gotar at polanet.pl  Wed Jul 16 22:09:34 2008
From: gotar at polanet.pl (Tomasz Pala)
Date: Wed, 16 Jul 2008 22:09:34 +0200
Subject: Packaging .py files
In-Reply-To: <200807162156.01036.glen@delfi.ee>
References: <89b6ba3a0807160607i694f7b15s95218947936689d9@mail.gmail.com>
	<200807162156.01036.glen@delfi.ee>
Message-ID: <20080716200934.GC20621@pepin.polanet.pl>

On Wed, Jul 16, 2008 at 21:56:00 +0300, Elan Ruusam?e wrote:

> can the packaging be automated like -debuginfo is right now?
> 
> i'd vote for -pysource, -source names :)

+1

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


From glen at delfi.ee  Wed Jul 16 22:56:08 2008
From: glen at delfi.ee (Elan =?iso-8859-2?q?Ruusam=E4e?=)
Date: Wed, 16 Jul 2008 23:56:08 +0300
Subject: vim-rt size (was Re: Packaging .py files)
In-Reply-To: <20080716200741.GA20621@pepin.polanet.pl>
References: <89b6ba3a0807160607i694f7b15s95218947936689d9@mail.gmail.com>
	<200807162200.33665.glen@delfi.ee>
	<20080716200741.GA20621@pepin.polanet.pl>
Message-ID: <200807162356.09538.glen@delfi.ee>

On Wednesday 16 July 2008 23:07, Tomasz Pala wrote:
> > as i have few systems where /usr is really small and can't be grown . (do
> > not ask why), but i like vim, mostly due it's syntax hiliting feature.
>
> Use excludedocs Luke.

/usr/share/vim/vim71/doc is not marked as %doc.
it's not online help for vim application (F1 fires it)

-- 
glen


From mmazur at kernel.pl  Wed Jul 16 23:07:38 2008
From: mmazur at kernel.pl (Mariusz Mazur)
Date: Wed, 16 Jul 2008 23:07:38 +0200
Subject: Packaging .py files
In-Reply-To: <89b6ba3a0807160607i694f7b15s95218947936689d9@mail.gmail.com>
References: <89b6ba3a0807160607i694f7b15s95218947936689d9@mail.gmail.com>
Message-ID: <200807162307.38770.mmazur@kernel.pl>

+1

Over the years I've grown quite tired of a lot of cases where PLD tries to be 
smarter then upstream and/or other distros and does something completely 
insignificant differently which results in having to patch up perfectly 
working apps. On the one hand I've got a lot of stuff to make my life easier 
(hey, vserver out of the box!) and on the other there are those little pesky 
oddities.

Python packaging is one such case.

(Others would be e.g. /bin/sh)


-- 
Judge others by their intentions and yourself by your results.
                                                                 Guy Kawasaki
Education is an admirable thing, but it is well to remember from
time to time that nothing that is worth knowing can be taught.
                                                                  Oscar Wilde


From gotar at polanet.pl  Wed Jul 16 23:57:35 2008
From: gotar at polanet.pl (Tomasz Pala)
Date: Wed, 16 Jul 2008 23:57:35 +0200
Subject: vim-rt size (was Re: Packaging .py files)
In-Reply-To: <200807162356.09538.glen@delfi.ee>
References: <89b6ba3a0807160607i694f7b15s95218947936689d9@mail.gmail.com>
	<200807162200.33665.glen@delfi.ee>
	<20080716200741.GA20621@pepin.polanet.pl>
	<200807162356.09538.glen@delfi.ee>
Message-ID: <20080716215734.GA4839@pepin.polanet.pl>

On Wed, Jul 16, 2008 at 23:56:08 +0300, Elan Ruusam?e wrote:

>> Use excludedocs Luke.
> 
> /usr/share/vim/vim71/doc is not marked as %doc.

Isn't it?

~:  du -sh /usr/share/vim/vim71/doc
280K    /usr/share/vim/vim71/doc

%doc %{_datadir}/vim/v*/doc/*.txt
%lang(pl) %doc %{_datadir}/vim/v*/doc/*.plx

> it's not online help for vim application (F1 fires it)

I know it is and I have never had it installed on my workstation.

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


From gotar at polanet.pl  Thu Jul 17 00:06:00 2008
From: gotar at polanet.pl (Tomasz Pala)
Date: Thu, 17 Jul 2008 00:06:00 +0200
Subject: Packaging .py files
In-Reply-To: <200807162307.38770.mmazur@kernel.pl>
References: <89b6ba3a0807160607i694f7b15s95218947936689d9@mail.gmail.com>
	<200807162307.38770.mmazur@kernel.pl>
Message-ID: <20080716220600.GB4839@pepin.polanet.pl>

On Wed, Jul 16, 2008 at 23:07:38 +0200, Mariusz Mazur wrote:

> Over the years I've grown quite tired of a lot of cases where PLD tries to be 

I'm tired too but it is a must have for reliable system.

> smarter then upstream and/or other distros and does something completely 
> insignificant differently which results in having to patch up perfectly 
> working apps.

These 'perfectly working apps' used to be security holes, functionality
breakers etc.

> On the one hand I've got a lot of stuff to make my life easier 
> (hey, vserver out of the box!) and on the other there are those little pesky 
> oddities.

If you don't value being The Right Way just use some FC, Debian, Ubuntu
or other.

> Python packaging is one such case.

That's one I don't care for much.

> (Others would be e.g. /bin/sh)

Yeah, let's use fucked up bash. The next step would be to use FC spec
files and simple package - * instead of file listings in subpackages.
The end of this road is even much simplier - ./configure; make; make
install.

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


From mmazur at kernel.pl  Thu Jul 17 00:30:40 2008
From: mmazur at kernel.pl (Mariusz Mazur)
Date: Thu, 17 Jul 2008 00:30:40 +0200
Subject: Packaging .py files
In-Reply-To: <20080716220600.GB4839@pepin.polanet.pl>
References: <89b6ba3a0807160607i694f7b15s95218947936689d9@mail.gmail.com>
	<200807162307.38770.mmazur@kernel.pl>
	<20080716220600.GB4839@pepin.polanet.pl>
Message-ID: <200807170030.40491.mmazur@kernel.pl>

Dnia czwartek, 17 lipca 2008, Tomasz Pala napisa?:
> On Wed, Jul 16, 2008 at 23:07:38 +0200, Mariusz Mazur wrote:
> > Over the years I've grown quite tired of a lot of cases where PLD tries
> > to be
>
> I'm tired too but it is a must have for reliable system.

It's not a reliable system when any application can fail because it either 
expects something that all of the other distros, except us, have (sh -> bash) 
or we've done something to it without having much clue about original 
developers' reasons for a particular choice (ripping out internal versions of 
various libs).

> > smarter then upstream and/or other distros and does something completely
> > insignificant differently which results in having to patch up perfectly
> > working apps.
>
> These 'perfectly working apps' used to be security holes, functionality
> breakers etc.

If they in fact are, to the extent we're not as much of security zealots as, 
say, openbsd, it's obviously better to patch them.

Both the python and /bin/sh cases don't fall under any of the above. Let's try 
to be specific.

> > On the one hand I've got a lot of stuff to make my life easier
> > (hey, vserver out of the box!) and on the other there are those little
> > pesky oddities.
>
> If you don't value being The Right Way just use some FC, Debian, Ubuntu
> or other.

PLD also has The Right Way, the Have It Just Work rule. Non-interactive rpm 
installations, sane and working out-of-the-box default configs, a lot 
of %post scripts to make sure everything's integrated, etc, etc. Going 
against de facto standards (/bin/sh) and actual standards (python -- I'm 
quite sure it's authors never meant for it to be distributed the way we do) 
both break the rule.

> > (Others would be e.g. /bin/sh)
>
> Yeah, let's use fucked up bash. The next step would be to use FC spec
> files and simple package - * instead of file listings in subpackages.
> The end of this road is even much simplier - ./configure; make; make
> install.

The only part where we actually prefer not to have bash is where our own (made 
in-house) scripts are concerned. All other scripts should be run with what 
their authors expected, and that's bash (the Have It Just Work rule). The 
solution is quite trivial -- have our scripts invoke pdksh directly and leave 
bash under /bin/sh.



Bottom line is -- we're quite an invasive distro anyway, as far as patching 
apps goes, so it's in our best interest to get rid of those modifications 
that have no real life value and are only a pain in the ass.

I'd urge the Th RM (well, Ti too ;) to Do The Right Thing wrt to both python 
and sh/bash. If it's really an unpopular decision, it'll get overruled in 
CDG. And if not, we'll have a few less quirks to irritate us.


-- 
Judge others by their intentions and yourself by your results.
                                                                 Guy Kawasaki
Education is an admirable thing, but it is well to remember from
time to time that nothing that is worth knowing can be taught.
                                                                  Oscar Wilde


From wolf.pld at gmail.com  Thu Jul 17 01:45:39 2008
From: wolf.pld at gmail.com (Bartosz Taudul)
Date: Thu, 17 Jul 2008 01:45:39 +0200
Subject: Packaging .py files
In-Reply-To: <200807170030.40491.mmazur@kernel.pl>
References: <89b6ba3a0807160607i694f7b15s95218947936689d9@mail.gmail.com>
	<200807162307.38770.mmazur@kernel.pl>
	<20080716220600.GB4839@pepin.polanet.pl>
	<200807170030.40491.mmazur@kernel.pl>
Message-ID: <20080716234539.GA24809@bajzel>

On Thu, Jul 17, 2008 at 12:30:40AM +0200, Mariusz Mazur wrote:
> It's not a reliable system when any application can fail because it either 
> expects something that all of the other distros, except us, have (sh -> bash) 
Yes, condoning bad code practices is the way to go. Go install your
ubuntu.

> or we've done something to it without having much clue about original 
> developers' reasons for a particular choice (ripping out internal versions of 
> various libs).
Half the time the original developers "don't have a clue", so your
argument fails.

> (python -- I'm 
> quite sure it's authors never meant for it to be distributed the way we do) 
The more I know about python the more I am assured it's a joke language.

> The only part where we actually prefer not to have bash is where our own (made 
You and who else?

> in-house) scripts are concerned. All other scripts should be run with what 
> their authors expected, and that's bash (the Have It Just Work rule). The 
Bullshit. The scripts that expect bash have "#!/bin/bash" in header, not
"#!/bin/sh".

wolf
-- 
  Bartek   .  
  Taudul   :  
          .:....................................................................
w o l f @ p l d - l i n u x . o r g            .:. http://wolf.valkyrie.one.pl/


From mmazur at kernel.pl  Thu Jul 17 02:14:35 2008
From: mmazur at kernel.pl (Mariusz Mazur)
Date: Thu, 17 Jul 2008 02:14:35 +0200
Subject: Packaging .py files
In-Reply-To: <20080716234539.GA24809@bajzel>
References: <89b6ba3a0807160607i694f7b15s95218947936689d9@mail.gmail.com>
	<200807170030.40491.mmazur@kernel.pl>
	<20080716234539.GA24809@bajzel>
Message-ID: <200807170214.36065.mmazur@kernel.pl>

Dnia czwartek, 17 lipca 2008, Bartosz Taudul napisa?:
> Yes, condoning bad code practices is the way to go. Go install your
> ubuntu.

It's "bad" in theory. In practice, for the past maaaany years nobody gives a 
shit about theory in case of /bin/sh. So that's top score for theory and a 
FAIL on the reality check.

> > or we've done something to it without having much clue about original
> > developers' reasons for a particular choice (ripping out internal
> > versions of various libs).
>
> Half the time the original developers "don't have a clue", so your
> argument fails.

Then fix upstream. You have no idea whether they do or don't have a clue if 
you don't ask first. I'd rather default to assuming that the guys who wrote 
the stuff know better than Joe Random Developer does. I'm actually *using* 
their code, so I kind of assume they have some kind of clue.

> > (python -- I'm
> > quite sure it's authors never meant for it to be distributed the way we
> > do)
>
> The more I know about python the more I am assured it's a joke language.

That's not an argument. Anything more on point you'd like to add wrt to the 
python discussion?

> > The only part where we actually prefer not to have bash is where our own
> > (made in-house) scripts are concerned.
>
> You and who else?

And concerning the point of that sentence? Anything you'd like to say? Maybe 
that it's false or sth? With some specific reasons as to why?

> > All other scripts should be run with 
> > what their authors expected, and that's bash (the Have It Just Work
> > rule). The
>
> Bullshit. The scripts that expect bash have "#!/bin/bash" in header, not
> "#!/bin/sh".

That's true only for the scripts whose authors (a) know there are distros that 
don't use bash as sh and (b) give a shit. That's a minority. Doing it 'our 
way' is simply pointless (what exactly do we gain?).


-- 
Judge others by their intentions and yourself by your results.
                                                                 Guy Kawasaki
Education is an admirable thing, but it is well to remember from
time to time that nothing that is worth knowing can be taught.
                                                                  Oscar Wilde


From aredridel at nbtsc.org  Thu Jul 17 02:37:46 2008
From: aredridel at nbtsc.org (Aria Stewart)
Date: Wed, 16 Jul 2008 18:37:46 -0600
Subject: Packaging .py files
In-Reply-To: <200807170214.36065.mmazur@kernel.pl>
References: <89b6ba3a0807160607i694f7b15s95218947936689d9@mail.gmail.com>
	<200807170030.40491.mmazur@kernel.pl>
	<20080716234539.GA24809@bajzel>
	<200807170214.36065.mmazur@kernel.pl>
Message-ID: <AA530D51-87D2-4F29-BE5A-552DA6C0C37E@nbtsc.org>


On Jul 16, 2008, at 6:14 PM, Mariusz Mazur wrote:
>
>>> All other scripts should be run with
>>> what their authors expected, and that's bash (the Have It Just Work
>>> rule). The
>>
>> Bullshit. The scripts that expect bash have "#!/bin/bash" in  
>> header, not
>> "#!/bin/sh".
>
> That's true only for the scripts whose authors (a) know there are  
> distros that
> don't use bash as sh and (b) give a shit. That's a minority. Doing  
> it 'our
> way' is simply pointless (what exactly do we gain?).


I prefer to use software written by people who Give A Shit.

Aria Stewart
aredridel at nbtsc.org





From gotar at polanet.pl  Thu Jul 17 10:24:52 2008
From: gotar at polanet.pl (Tomasz Pala)
Date: Thu, 17 Jul 2008 10:24:52 +0200
Subject: Packaging .py files
In-Reply-To: <200807170030.40491.mmazur@kernel.pl>
References: <89b6ba3a0807160607i694f7b15s95218947936689d9@mail.gmail.com>
	<200807162307.38770.mmazur@kernel.pl>
	<20080716220600.GB4839@pepin.polanet.pl>
	<200807170030.40491.mmazur@kernel.pl>
Message-ID: <20080717082452.GA7635@pepin.polanet.pl>

On Thu, Jul 17, 2008 at 00:30:40 +0200, Mariusz Mazur wrote:

> It's not a reliable system when any application can fail because it either 
> expects something that all of the other distros, except us, have (sh -> bash) 
  ^^^^^^^

Unfortunately these apps do not expect anything - they have some piece
of code just because it have worked while typing in dumb monkey-mode.
I'd prefer not to use such apps as they are (let me repeat) serious
security threat.

Do you remember a situation a few years ago when some malicious code was
inserted into ./configure script? PLD was not affected thanks to another
PITA - AC/AM regeneration.

> or we've done something to it without having much clue about original 
> developers' reasons for a particular choice (ripping out internal versions of 
> various libs).

So just use binary shipped FF, OOo and other.
And BTW it's not their choice again - they exist because of the same
dumb monkey-mode coding.
The Real Programmer ships patch for mainstream lib (like it was in FUR
and librapi2), unless this library is seriously broken - in this case it
shoudn't be used anyway.

> If they in fact are, to the extent we're not as much of security zealots as, 
> say, openbsd, it's obviously better to patch them.

Doesn't our patches go upstream? If they are rejected it usualy means,
that authors are really dumb or don't give a shit. Either way we do The
Right Thing.

> Both the python and /bin/sh cases don't fall under any of the above. Let's try 
> to be specific.

OK, last time:      bash      is         broken. I don't want this
GNU/shitty shell even to be installed on my machines, unfortunatelly some
idiots use its 'features', just because they are too lazy to read SUSv3
spec (like using ((var++)) instead of var=$((var+1))).

> PLD also has The Right Way, the Have It Just Work rule. Non-interactive rpm 
> installations, sane and working out-of-the-box default configs, a lot 
> of %post scripts to make sure everything's integrated, etc, etc. Going 
> against de facto standards (/bin/sh)

It is not de facto or not standard - I don't remember having it on some
HP or AIX machines.

> in-house) scripts are concerned. All other scripts should be run with what 
> their authors expected, and that's bash (the Have It Just Work rule). The 

I don't remember changing /bin/bash to be something different. And that
is used when author EXPECTS it.

> solution is quite trivial -- have our scripts invoke pdksh directly and leave 
> bash under /bin/sh.

No - Have It Just Work rule is trivial other way: if a script is too messed
just change bang line to bash. Bash seems not to care much of argv[0].

> Bottom line is -- we're quite an invasive distro anyway, as far as patching 
> apps goes, so it's in our best interest to get rid of those modifications 
> that have no real life value and are only a pain in the ass.

/bin/sh has the same value as:
1. being FHS compliant
2. micropackages
3. spec files guidelines
4. lang() and %doc stuff

> I'd urge the Th RM (well, Ti too ;) to Do The Right Thing wrt to both python 
> and sh/bash. If it's really an unpopular decision, it'll get overruled in 
> CDG. And if not, we'll have a few less quirks to irritate us.

And you will have a few developers and users left, as PLD would have
still less and less to offer.

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


From gotar at polanet.pl  Thu Jul 17 10:26:46 2008
From: gotar at polanet.pl (Tomasz Pala)
Date: Thu, 17 Jul 2008 10:26:46 +0200
Subject: Packaging .py files
In-Reply-To: <20080716234539.GA24809@bajzel>
References: <89b6ba3a0807160607i694f7b15s95218947936689d9@mail.gmail.com>
	<200807162307.38770.mmazur@kernel.pl>
	<20080716220600.GB4839@pepin.polanet.pl>
	<200807170030.40491.mmazur@kernel.pl>
	<20080716234539.GA24809@bajzel>
Message-ID: <20080717082645.GB7635@pepin.polanet.pl>

On Thu, Jul 17, 2008 at 01:45:39 +0200, Bartosz Taudul wrote:

> The more I know about python the more I am assured it's a joke language.

I felt the same when saw it's promo movie.

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


From gotar at polanet.pl  Thu Jul 17 10:42:25 2008
From: gotar at polanet.pl (Tomasz Pala)
Date: Thu, 17 Jul 2008 10:42:25 +0200
Subject: Packaging .py files
In-Reply-To: <200807170214.36065.mmazur@kernel.pl>
References: <89b6ba3a0807160607i694f7b15s95218947936689d9@mail.gmail.com>
	<200807170030.40491.mmazur@kernel.pl>
	<20080716234539.GA24809@bajzel>
	<200807170214.36065.mmazur@kernel.pl>
Message-ID: <20080717084225.GC7635@pepin.polanet.pl>

On Thu, Jul 17, 2008 at 02:14:35 +0200, Mariusz Mazur wrote:

>> Bullshit. The scripts that expect bash have "#!/bin/bash" in header, not
>> "#!/bin/sh".
> 
> That's true only for the scripts whose authors (a) know there are distros that 
> don't use bash as sh and

FALSE

using /bin/sh means using ANY POSIX shell.


Oh, BTW your 'de facto standard' reminds me Microsoft HTML - 'de facto
standard' with Microsoft extensions and incompatibilities with HTML.

> (b) give a shit. That's a minority. Doing it 'our 
> way' is simply pointless (what exactly do we gain?).

The same as with AC/AM regeneration, getting rid of internal libs,
recompiling packages (hey, there are binaries available at websites,
isn't it?), keeping of FHS, separating *debuginfo*, *devel*, *static*
lang(), %doc etc etc. Let's put entire KDE4, GNOME and OOo into /opt
(who gives a shit? It Just Works). Let programs keep their configuration
in /usr/local/bin/etc (who gives a shit? It Just Works!).

I suggest discussing it all together with changing template.spec (it's
enough to unpack original binary and put them into %files section) and
changing distro name to PLbuntu (hey, small 'b' letter looks like 'D'!).

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


From wolf.pld at gmail.com  Thu Jul 17 11:24:24 2008
From: wolf.pld at gmail.com (Bartosz Taudul)
Date: Thu, 17 Jul 2008 11:24:24 +0200
Subject: Packaging .py files
In-Reply-To: <200807170214.36065.mmazur@kernel.pl>
References: <89b6ba3a0807160607i694f7b15s95218947936689d9@mail.gmail.com>
	<200807170030.40491.mmazur@kernel.pl> <20080716234539.GA24809@bajzel>
	<200807170214.36065.mmazur@kernel.pl>
Message-ID: <6118a73d0807170224x2ea8b931x4b4fe9d463c3cf44@mail.gmail.com>

2008/7/17 Mariusz Mazur <mmazur at kernel.pl>:
> > Yes, condoning bad code practices is the way to go. Go install your
> > ubuntu.
> It's "bad" in theory. In practice, for the past maaaany years nobody gives a
> shit about theory in case of /bin/sh.
Bad for them.

> So that's top score for theory and a FAIL on the reality check.
Flushing quality down the toilet is not an option.

> > Half the time the original developers "don't have a clue", so your
> > argument fails.
> Then fix upstream.
The number of sane developers without inferiority complex is very low
and I don't like to talk with idiots if I don't have to.

> I'd rather default to assuming that the guys who wrote
> the stuff know better than Joe Random Developer does. I'm actually *using*
> their code, so I kind of assume they have some kind of clue.
I actually have enough *experience* to *know* that most of the time they don't.

> > > (python -- I'm
> > > quite sure it's authors never meant for it to be distributed the way we
> > > do)
> > The more I know about python the more I am assured it's a joke language.
> That's not an argument.
Running debug code by default and requiring special knobs for having
release code ran is kind of funny if I don't have to use it.

> > > The only part where we actually prefer not to have bash is where our own
> > > (made in-house) scripts are concerned.
> > You and who else?
> And concerning the point of that sentence? Anything you'd like to say? Maybe
> that it's false or sth? With some specific reasons as to why?
Of course it's false. You are speaking strictly for yourself, yet you
are manipulating everyone to think that's a widely applauded opinion
(by using "we" instead of "I").

> > Bullshit. The scripts that expect bash have "#!/bin/bash" in header, not
> > "#!/bin/sh".
> That's true only for the scripts whose authors (a) know there are distros that
> don't use bash as sh
You were saying something about developers "having a clue" recently?

> (b) give a shit.
We know that you don't.

> Doing it 'our way' is simply pointless
Our way? https://wiki.ubuntu.com/DashAsBinSh

> (what exactly do we gain?).
Speed, correctness, etc.


From gotar at polanet.pl  Thu Jul 17 11:54:06 2008
From: gotar at polanet.pl (Tomasz Pala)
Date: Thu, 17 Jul 2008 11:54:06 +0200
Subject: Packaging .py files
In-Reply-To: <6118a73d0807170224x2ea8b931x4b4fe9d463c3cf44@mail.gmail.com>
References: <89b6ba3a0807160607i694f7b15s95218947936689d9@mail.gmail.com>
	<200807170030.40491.mmazur@kernel.pl>
	<20080716234539.GA24809@bajzel>
	<200807170214.36065.mmazur@kernel.pl>
	<6118a73d0807170224x2ea8b931x4b4fe9d463c3cf44@mail.gmail.com>
Message-ID: <20080717095406.GA28886@pepin.polanet.pl>

On Thu, Jul 17, 2008 at 11:24:24 +0200, Bartosz Taudul wrote:

>> Doing it 'our way' is simply pointless
> Our way? https://wiki.ubuntu.com/DashAsBinSh

And at this point we could end this discussion or change it's subject to
'pdksh or dash'.

One more example of 'giving a damn shit about correctness' for MM: gcc.

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


From mmazur at kernel.pl  Thu Jul 17 16:50:24 2008
From: mmazur at kernel.pl (Mariusz Mazur)
Date: Thu, 17 Jul 2008 16:50:24 +0200
Subject: Packaging .py files
In-Reply-To: <6118a73d0807170224x2ea8b931x4b4fe9d463c3cf44@mail.gmail.com>
References: <89b6ba3a0807160607i694f7b15s95218947936689d9@mail.gmail.com>
	<200807170214.36065.mmazur@kernel.pl>
	<6118a73d0807170224x2ea8b931x4b4fe9d463c3cf44@mail.gmail.com>
Message-ID: <200807171650.24411.mmazur@kernel.pl>

Dnia czwartek, 17 lipca 2008, Bartosz Taudul napisa?:
> The number of sane developers without inferiority complex is very low
> and I don't like to talk with idiots if I don't have to.

That's why I prefer not to have too many pld specific changes, since it's 
easier to merge something upstream when you can point at a major distro and 
say that the current way also breaks on e.g. Fedora.

> > Doing it 'our way' is simply pointless
>
> Our way? https://wiki.ubuntu.com/DashAsBinSh

Ok, that's enough for me if there are other mainstream distros that don't use 
bash.


Regarding original thread, I'm still in favor of packaging *.py files in base 
packages.

One other option to consider. According to this document:
http://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html

Debian does the following:

"If a package provides any binary-independent modules (foo.py files), the 
corresponding bytecompiled modules (foo.pyc files) and optimized modules 
(foo.pyo files) must not ship in the package. Instead, they should be 
generated in the package's postinst, and removed in the package's prerm. The 
package's prerm has to make sure that both foo.pyc and foo.pyo are removed."

This obviously makes installation a bit slower, but has the advantage of being 
python-version independent, meaning when you upgrade python, you don't have 
to rebuild all python-dependant packages and reinstall them -- postinst 
scripts just rebuild *.py{c,o} files on your system and you're done.

Major problem -- it's slower.

-- 
Judge others by their intentions and yourself by your results.
                                                                 Guy Kawasaki
Education is an admirable thing, but it is well to remember from
time to time that nothing that is worth knowing can be taught.
                                                                  Oscar Wilde


From mmazur at kernel.pl  Thu Jul 17 17:11:20 2008
From: mmazur at kernel.pl (Mariusz Mazur)
Date: Thu, 17 Jul 2008 17:11:20 +0200
Subject: [ANNOUNCEMENT] Bugzilla >/dev/null, switching to launchpad.net
In-Reply-To: <20080716110307.GB26506@mysza.eu.org>
References: <200807161243.25745.mmazur@kernel.pl>
	<20080716110307.GB26506@mysza.eu.org>
Message-ID: <200807171711.20367.mmazur@kernel.pl>

Dnia ?roda, 16 lipca 2008, Adam Go??biowski napisa?:
> It looks like launchpad doesn't send mail reports to bugs at pld-linux.org,
> please fix this.

I need the cooperation of the moderator first. Who might that be?

-- 
Judge others by their intentions and yourself by your results.
                                                                 Guy Kawasaki
Education is an admirable thing, but it is well to remember from
time to time that nothing that is worth knowing can be taught.
                                                                  Oscar Wilde


From mmazur at kernel.pl  Thu Jul 17 17:17:21 2008
From: mmazur at kernel.pl (Mariusz Mazur)
Date: Thu, 17 Jul 2008 17:17:21 +0200
Subject: Packaging .py files
In-Reply-To: <20080717082452.GA7635@pepin.polanet.pl>
References: <89b6ba3a0807160607i694f7b15s95218947936689d9@mail.gmail.com>
	<200807170030.40491.mmazur@kernel.pl>
	<20080717082452.GA7635@pepin.polanet.pl>
Message-ID: <200807171717.21892.mmazur@kernel.pl>

Dnia czwartek, 17 lipca 2008, Tomasz Pala napisa?:
> Unfortunately these apps do not expect anything - they have some piece
> of code just because it have worked while typing in dumb monkey-mode.
> I'd prefer not to use such apps as they are (let me repeat) serious
> security threat.

I know, my point is, that there are specific cases, where an 'error' is too 
widespread to try to fix everything and it might make more sense to just stop 
enforcing our way and do what everybody else does. On the other hand, I'm 
quite attached to PLD being for example FHS-strict.

> So just use binary shipped FF, OOo and other.

I use ux-oo, because a long time ago I got tired of our OO blowing up every 
second upgrade. I really do think that such integration nightmares as OO or, 
dunno, big java apps (especially considering java has it's own standards for 
allmost everything and you don't gain anything by recompiling bytecode) 
aren't worth trying to force our ways onto and it makes more sense to make 
more of an effort to accommodate the stuff that's released by upstream. It's 
a separate discussion though.

> And BTW it's not their choice again - they exist because of the same
> dumb monkey-mode coding.
> The Real Programmer ships patch for mainstream lib (like it was in FUR
> and librapi2), unless this library is seriously broken - in this case it
> shoudn't be used anyway.

At a certain complexity level it might not just be possible/worth it, to do it 
The Right Way.

> Doesn't our patches go upstream? If they are rejected it usualy means,
> that authors are really dumb or don't give a shit. Either way we do The
> Right Thing.

A) Authors often have different goals then distributions, especially 
non-mainstream ones, like PLD. So I'd guess more often then not, they'd be 
saying we're the idiots. B) We can't save the world. Having more and more 
pld-specific patches makes it harder to maintain PLD so in specific cases it 
might make more sense to just give up and do what everybody else does.

> And you will have a few developers and users left, as PLD would have
> still less and less to offer.

I'm in favor of PLD being a compromise between being a geek's dream and 
something that's actually usable without having to patch your way trough 
every app.


-- 
Judge others by their intentions and yourself by your results.
                                                                 Guy Kawasaki
Education is an admirable thing, but it is well to remember from
time to time that nothing that is worth knowing can be taught.
                                                                  Oscar Wilde


From gotar at polanet.pl  Thu Jul 17 18:02:19 2008
From: gotar at polanet.pl (Tomasz Pala)
Date: Thu, 17 Jul 2008 18:02:19 +0200
Subject: Packaging .py files
In-Reply-To: <200807171717.21892.mmazur@kernel.pl>
References: <89b6ba3a0807160607i694f7b15s95218947936689d9@mail.gmail.com>
	<200807170030.40491.mmazur@kernel.pl>
	<20080717082452.GA7635@pepin.polanet.pl>
	<200807171717.21892.mmazur@kernel.pl>
Message-ID: <20080717160218.GA11149@pepin.polanet.pl>

On Thu, Jul 17, 2008 at 17:17:21 +0200, Mariusz Mazur wrote:

> I know, my point is, that there are specific cases, where an 'error' is too 
> widespread to try to fix everything and it might make more sense to just stop 
> enforcing our way and do what everybody else does. On the other hand, I'm 
> quite attached to PLD being for example FHS-strict.

Our policy seems to be the winning one - not only other distros try
harder to keep standards, app developers too. Have you ever faced
rejecting some bashizm patch? World wants to be standarized, it's
popular.

> second upgrade. I really do think that such integration nightmares as OO or, 
> dunno, big java apps (especially considering java has it's own standards for 
> allmost everything and you don't gain anything by recompiling bytecode) 
> aren't worth trying to force our ways onto and it makes more sense to make 
> more of an effort to accommodate the stuff that's released by upstream. It's 
> a separate discussion though.

I agree. Because in this case we are 'dumb monkeys' trying to recompile
everything. However it's not /bin/sh case.

> At a certain complexity level it might not just be possible/worth it, to do it 
> The Right Way.

Fixing bashizm is not complex. After all one can change just bang line.
I'm far from making Oracle FHS-compliant.

>> Doesn't our patches go upstream? If they are rejected it usualy means,
>> that authors are really dumb or don't give a shit. Either way we do The
>> Right Thing.
> 
> A) Authors often have different goals then distributions, especially 

Shell scripts are usually beyond any goals, they exist just because they
are handy.

> non-mainstream ones, like PLD. So I'd guess more often then not, they'd be 
> saying we're the idiots.

Some examples of rejecting bashizm patch?

> B) We can't save the world. Having more and more 
> pld-specific patches makes it harder to maintain PLD so in specific cases it 
> might make more sense to just give up and do what everybody else does.

FHS is much more complex than bash/pdksh issues, as well as handling
compressed %doc in internal help browsers.

> I'm in favor of PLD being a compromise between being a geek's dream and 
> something that's actually usable without having to patch your way trough 
> every app.

There's only ca. 30 bash related patches in SOURCES. It's not every app.

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


From qboosh at pld-linux.org  Thu Jul 17 18:06:23 2008
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Thu, 17 Jul 2008 18:06:23 +0200
Subject: Packaging .py files
In-Reply-To: <200807171650.24411.mmazur@kernel.pl>
References: <89b6ba3a0807160607i694f7b15s95218947936689d9@mail.gmail.com>
	<200807170214.36065.mmazur@kernel.pl>
	<6118a73d0807170224x2ea8b931x4b4fe9d463c3cf44@mail.gmail.com>
	<200807171650.24411.mmazur@kernel.pl>
Message-ID: <20080717160623.GA5674@stranger.qboosh.pl>

On Thu, Jul 17, 2008 at 04:50:24PM +0200, Mariusz Mazur wrote:
> Dnia czwartek, 17 lipca 2008, Bartosz Taudul napisa?:
> > The number of sane developers without inferiority complex is very low
> > and I don't like to talk with idiots if I don't have to.
> 
> That's why I prefer not to have too many pld specific changes, since it's 
> easier to merge something upstream when you can point at a major distro and 
> say that the current way also breaks on e.g. Fedora.
> 
> > > Doing it 'our way' is simply pointless
> >
> > Our way? https://wiki.ubuntu.com/DashAsBinSh
> 
> Ok, that's enough for me if there are other mainstream distros that don't use 
> bash.

And remember that most of software we use (except some system tools)
could be used on UNIX, not just Linux.

Is there any other OS (beside some Linux distros and Hurd) which uses
bash as sh?

On *BSD, Solaris, AIX etc. there is even no /bin/bash (in most cases you
can find it in /usr/local/bin, if GNU tools are installed).

> Regarding original thread, I'm still in favor of packaging *.py files in base 
> packages.
> 
> One other option to consider. According to this document:
> http://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html
> 
> Debian does the following:
> 
> "If a package provides any binary-independent modules (foo.py files), the 
> corresponding bytecompiled modules (foo.pyc files) and optimized modules 
> (foo.pyo files) must not ship in the package. Instead, they should be 
> generated in the package's postinst, and removed in the package's prerm. The 
> package's prerm has to make sure that both foo.pyc and foo.pyo are removed."
> 
> This obviously makes installation a bit slower, but has the advantage of being 
> python-version independent, meaning when you upgrade python, you don't have 
> to rebuild all python-dependant packages and reinstall them -- postinst 
> scripts just rebuild *.py{c,o} files on your system and you're done.
> 
> Major problem -- it's slower.

Major problem is that there is no way to verify *.pyc consistency
against package database. One can place any malicious code in *.pyc
leaving *.py untouched and it's hard to detect.

That's why I don't like the Debian way.


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


From zbyniu at geocarbon.pl  Thu Jul 17 18:10:57 2008
From: zbyniu at geocarbon.pl (Zbyniu Krzystolik)
Date: Thu, 17 Jul 2008 18:10:57 +0200
Subject: [OT] Packaging .py files
In-Reply-To: <200807170030.40491.mmazur@kernel.pl>
References: <89b6ba3a0807160607i694f7b15s95218947936689d9@mail.gmail.com>
	<200807162307.38770.mmazur@kernel.pl>
	<20080716220600.GB4839@pepin.polanet.pl>
	<200807170030.40491.mmazur@kernel.pl>
Message-ID: <20080717161057.GA11861@geocarbon.pl>

Mniej wiecej Thu, Jul 17, 2008 at 12:30:40AM +0200, zainteresowany Mariusz Mazur rzekl:
> Dnia czwartek, 17 lipca 2008, Tomasz Pala napisa?:
> > These 'perfectly working apps' used to be security holes, functionality
> > breakers etc.
> 
> If they in fact are, to the extent we're not as much of security zealots as, 
> say, openbsd, it's obviously better to patch them.

http://tinyurl.com/6cxdjw

Are you sure? ;)

Zbyniu 
-- 
%% Absolutely nothing we trust %%


From patrys at pld-linux.org  Thu Jul 17 18:37:06 2008
From: patrys at pld-linux.org (Patryk Zawadzki)
Date: Thu, 17 Jul 2008 18:37:06 +0200
Subject: [ANNOUNCEMENT] Bugzilla >/dev/null, switching to launchpad.net
In-Reply-To: <200807171711.20367.mmazur@kernel.pl>
References: <200807161243.25745.mmazur@kernel.pl>
	<20080716110307.GB26506@mysza.eu.org>
	<200807171711.20367.mmazur@kernel.pl>
Message-ID: <89b6ba3a0807170937q6bce00c1p459a31f159690dda@mail.gmail.com>

2008/7/17 Mariusz Mazur <mmazur at kernel.pl>:
> Dnia ?roda, 16 lipca 2008, Adam Go??biowski napisa?:
>> It looks like launchpad doesn't send mail reports to bugs at pld-linux.org,
>> please fix this.
> I need the cooperation of the moderator first. Who might that be?

Moderator of what?

-- 
Patryk Zawadzki
PLD Linux Distribution

From mmazur at kernel.pl  Thu Jul 17 19:02:28 2008
From: mmazur at kernel.pl (Mariusz Mazur)
Date: Thu, 17 Jul 2008 19:02:28 +0200
Subject: [ANNOUNCEMENT] Bugzilla >/dev/null, switching to launchpad.net
In-Reply-To: <89b6ba3a0807170937q6bce00c1p459a31f159690dda@mail.gmail.com>
References: <200807161243.25745.mmazur@kernel.pl>
	<200807171711.20367.mmazur@kernel.pl>
	<89b6ba3a0807170937q6bce00c1p459a31f159690dda@mail.gmail.com>
Message-ID: <200807171902.28889.mmazur@kernel.pl>

Dnia czwartek, 17 lipca 2008, Patryk Zawadzki napisa?:
> 2008/7/17 Mariusz Mazur <mmazur at kernel.pl>:
> > Dnia ?roda, 16 lipca 2008, Adam Go??biowski napisa?:
> >> It looks like launchpad doesn't send mail reports to bugs at pld-linux.org,
> >> please fix this.
> >
> > I need the cooperation of the moderator first. Who might that be?
>
> Moderator of what?

pld-bugs at lists. In order to subscribe. I think.

-- 
Judge others by their intentions and yourself by your results.
                                                                 Guy Kawasaki
Education is an admirable thing, but it is well to remember from
time to time that nothing that is worth knowing can be taught.
                                                                  Oscar Wilde


From deejay1 at srem.org  Thu Jul 17 19:34:51 2008
From: deejay1 at srem.org (=?UTF-8?Q?=C5=81ukasz_Jerna=C5=9B?=)
Date: Thu, 17 Jul 2008 19:34:51 +0200
Subject: [OT] Packaging .py files
In-Reply-To: <20080717161057.GA11861@geocarbon.pl>
References: <89b6ba3a0807160607i694f7b15s95218947936689d9@mail.gmail.com>
	<200807162307.38770.mmazur@kernel.pl>
	<20080716220600.GB4839@pepin.polanet.pl>
	<200807170030.40491.mmazur@kernel.pl>
	<20080717161057.GA11861@geocarbon.pl>
Message-ID: <1216316091.5676.0.camel@betty.paderewskiego11>

Dnia 2008-07-17, czw o godzinie 18:10 +0200, Zbyniu Krzystolik pisze:
> Mniej wiecej Thu, Jul 17, 2008 at 12:30:40AM +0200, zainteresowany Mariusz Mazur rzekl:
> > Dnia czwartek, 17 lipca 2008, Tomasz Pala napisa?:
> > > These 'perfectly working apps' used to be security holes, functionality
> > > breakers etc.
> > 
> > If they in fact are, to the extent we're not as much of security zealots as, 
> > say, openbsd, it's obviously better to patch them.
> 
> http://tinyurl.com/6cxdjw
> 
> Are you sure? ;)

ROTFL! reddit, digg, slashdot, wykop anyone? ;>

-- 
DeeJay1



From patrys at pld-linux.org  Thu Jul 17 19:47:31 2008
From: patrys at pld-linux.org (Patryk Zawadzki)
Date: Thu, 17 Jul 2008 19:47:31 +0200
Subject: Packaging .py files
In-Reply-To: <20080717160623.GA5674@stranger.qboosh.pl>
References: <89b6ba3a0807160607i694f7b15s95218947936689d9@mail.gmail.com>
	<200807170214.36065.mmazur@kernel.pl>
	<6118a73d0807170224x2ea8b931x4b4fe9d463c3cf44@mail.gmail.com>
	<200807171650.24411.mmazur@kernel.pl>
	<20080717160623.GA5674@stranger.qboosh.pl>
Message-ID: <89b6ba3a0807171047q505f91cahf6d6252a50827a7c@mail.gmail.com>

2008/7/17 Jakub Bogusz <qboosh at pld-linux.org>:
> And remember that most of software we use (except some system tools)
> could be used on UNIX, not just Linux.

That's true. And it's also true we are now forced by our own policies
to "fix" stuff that *might* become a future issue to some obscure *NIX
implementation. I'm not against going for a perfect world. I'm against
being forced to do something counter-productive in order to get some
work done (and I'm fairly sure I'm not the only one to package stuff
that I actually need).

In other words - we are one of the most limited distros when it comes
to resources. Pursuing a dream is one thing but we should not be
forced to do it. I'm not sure I want to lose my job for the sake of
saving the world. I want to be able to easily install a package and
get the goddamn python sources. Sure pydoc is useful but it's only
useful to the extent man is - you have to know the name of the
function in which case you probably don't need pydoc anymore (API
changes or implementation details that change but some coder decided
to rely on).

Not to mention the friggin' codegen.{py,pyc} substitution we need to
do for most of the packages containing bindings.

> Is there any other OS (beside some Linux distros and Hurd) which uses
> bash as sh?

Is there any PSD Solaris Distribution? (same kind of question)

-- 
Patryk Zawadzki
PLD Linux Distribution


From mmazur at kernel.pl  Thu Jul 17 19:56:48 2008
From: mmazur at kernel.pl (Mariusz Mazur)
Date: Thu, 17 Jul 2008 19:56:48 +0200
Subject: [OT] Packaging .py files
In-Reply-To: <1216316091.5676.0.camel@betty.paderewskiego11>
References: <89b6ba3a0807160607i694f7b15s95218947936689d9@mail.gmail.com>
	<20080717161057.GA11861@geocarbon.pl>
	<1216316091.5676.0.camel@betty.paderewskiego11>
Message-ID: <200807171956.48585.mmazur@kernel.pl>

Dnia czwartek, 17 lipca 2008, ?ukasz Jerna? napisa?:
> > http://tinyurl.com/6cxdjw
> >
> > Are you sure? ;)
>
> ROTFL! reddit, digg, slashdot, wykop anyone? ;>

Yes. A few days ago. Old news.

-- 
Judge others by their intentions and yourself by your results.
                                                                 Guy Kawasaki
Education is an admirable thing, but it is well to remember from
time to time that nothing that is worth knowing can be taught.
                                                                  Oscar Wilde


From deejay1 at srem.org  Thu Jul 17 20:06:44 2008
From: deejay1 at srem.org (=?UTF-8?Q?=C5=81ukasz_Jerna=C5=9B?=)
Date: Thu, 17 Jul 2008 20:06:44 +0200
Subject: [OT] Packaging .py files
In-Reply-To: <200807171956.48585.mmazur@kernel.pl>
References: <89b6ba3a0807160607i694f7b15s95218947936689d9@mail.gmail.com>
	<20080717161057.GA11861@geocarbon.pl>
	<1216316091.5676.0.camel@betty.paderewskiego11>
	<200807171956.48585.mmazur@kernel.pl>
Message-ID: <1216318004.5676.2.camel@betty.paderewskiego11>

Dnia 2008-07-17, czw o godzinie 19:56 +0200, Mariusz Mazur pisze:
> Dnia czwartek, 17 lipca 2008, ?ukasz Jerna? napisa?:
> > > http://tinyurl.com/6cxdjw
> > >
> > > Are you sure? ;)
> >
> > ROTFL! reddit, digg, slashdot, wykop anyone? ;>
> 
> Yes. A few days ago. Old news.

Buuuuuuu, missed that one :/

-- 
DeeJay1



From wolf.pld at gmail.com  Thu Jul 17 21:35:54 2008
From: wolf.pld at gmail.com (Bartosz Taudul)
Date: Thu, 17 Jul 2008 21:35:54 +0200
Subject: Packaging .py files
In-Reply-To: <89b6ba3a0807171047q505f91cahf6d6252a50827a7c@mail.gmail.com>
References: <89b6ba3a0807160607i694f7b15s95218947936689d9@mail.gmail.com>
	<200807170214.36065.mmazur@kernel.pl>
	<6118a73d0807170224x2ea8b931x4b4fe9d463c3cf44@mail.gmail.com>
	<200807171650.24411.mmazur@kernel.pl>
	<20080717160623.GA5674@stranger.qboosh.pl>
	<89b6ba3a0807171047q505f91cahf6d6252a50827a7c@mail.gmail.com>
Message-ID: <20080717193554.GA22736@bajzel>

On Thu, Jul 17, 2008 at 07:47:31PM +0200, Patryk Zawadzki wrote:
> I'm against
> being forced to do something counter-productive in order to get some
I'm against being forced to have some shit installed on my computer that
only some lazy developer needs.

> In other words - we are one of the most limited distros when it comes
> to resources.
We will surely have more people power if we start lowering quality and
blending with other distros.

> Pursuing a dream is one thing but we should not be
> forced to do it. I'm not sure I want to lose my job for the sake of
> saving the world.
Since when does PLD care about your job (or mine)? Saying that your
personal needs should come before general distros needs is extremely
arrogant IMO.

> I want to be able to easily install a package and
> get the goddamn python sources.
So install your python debuginfo equivalent and stop bitching. Why
should everyone be forced to have your crap, when they're just fine with
already compiled bytecode?

> Sure pydoc is useful but it's only
> useful to the extent man is - you have to know the name of the
> function in which case you probably don't need pydoc anymore (API
> changes or implementation details that change but some coder decided
> to rely on).
Yes, yes, very interesting. I will start packaging all the sources of
C libraries into main packages then, just so I can check if the code
really, *really*, *REALLY* does what the documentation and/or man pages
say. That's my favourite pastime activity, you know. I do it for the
kicks.

wolf
-- 
  Bartek   .  
  Taudul   :  
          .:....................................................................
w o l f @ p l d - l i n u x . o r g            .:. http://wolf.valkyrie.one.pl/


From mmazur at kernel.pl  Fri Jul 18 01:24:13 2008
From: mmazur at kernel.pl (Mariusz Mazur)
Date: Fri, 18 Jul 2008 01:24:13 +0200
Subject: Packaging .py files
In-Reply-To: <200807171717.21892.mmazur@kernel.pl>
References: <89b6ba3a0807160607i694f7b15s95218947936689d9@mail.gmail.com>
	<20080717082452.GA7635@pepin.polanet.pl>
	<200807171717.21892.mmazur@kernel.pl>
Message-ID: <200807180124.13829.mmazur@kernel.pl>

Dnia czwartek, 17 lipca 2008, Mariusz Mazur napisa?:
> B) We can't save the world. Having more and more
> pld-specific patches makes it harder to maintain PLD so in specific cases
> it might make more sense to just give up and do what everybody else does.

Some stats (that's HEAD):

[mmazur at klapek SPECS]$ ls |grep spec$|wc -l
13023
[mmazur at klapek SPECS]$ grep ^Patch -r .|wc -l
11841
[mmazur at klapek SPECS]$ egrep '^%patch|:%patch' -r .|wc -l
11470
[mmazur at klapek SPECS]$ grep -c ^Patch -r .|grep -c ':0$'
8226

This means 37% of our spec files are patched with each of those speces having 
almost 1.5 patch on average.

And now the same stats but only for packages that are currently found in 3.0 
(both in main and in ready/test/updates/whatever; note the list isn't 
perfect).

[mmazur at klapek THSPECS]$ ls *.spec|wc -l
5761
[mmazur at klapek THSPECS]$ grep ^Patch -r .|wc -l
5600
[mmazur at klapek THSPECS]$ egrep '^%patch|:%patch' -r .|wc -l
5445
[mmazur at klapek THSPECS]$ grep -c ^Patch -r .|grep -c ':0$'
3856

This means that Th contains ~45% of potential (in pure theory) packages 
available in PLD.
Additionally: 67% of Th packages are patched with also almost 1.5 patches on 
average.


At http://ep09.pld-linux.org/~mmazur/pld/thlist.txt is a list of spec files 
I've used, should anyone be interested in, dunno, maybe generating the same 
numbers for the past two years (monthly intervals) and plotting that?


-- 
Judge others by their intentions and yourself by your results.
                                                                 Guy Kawasaki
Education is an admirable thing, but it is well to remember from
time to time that nothing that is worth knowing can be taught.
                                                                  Oscar Wilde


From gotar at polanet.pl  Fri Jul 18 11:30:59 2008
From: gotar at polanet.pl (Tomasz Pala)
Date: Fri, 18 Jul 2008 11:30:59 +0200
Subject: Packaging .py files
In-Reply-To: <200807180124.13829.mmazur@kernel.pl>
References: <89b6ba3a0807160607i694f7b15s95218947936689d9@mail.gmail.com>
	<20080717082452.GA7635@pepin.polanet.pl>
	<200807171717.21892.mmazur@kernel.pl>
	<200807180124.13829.mmazur@kernel.pl>
Message-ID: <20080718093059.GA28904@pepin.polanet.pl>

On Fri, Jul 18, 2008 at 01:24:13 +0200, Mariusz Mazur wrote:

> > pld-specific patches makes it harder to maintain PLD so in specific cases

> Some stats (that's HEAD):
[...]
> This means 37% of our spec files are patched with each of those speces having 
> almost 1.5 patch on average.

OK, so let's follow Debian way - one huge patch per package, your stats
will feel better then.

Please filter out not PLD-specific patches! I gave you bash* stats - 30
patches.

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


From glen at delfi.ee  Sun Jul 20 11:58:50 2008
From: glen at delfi.ee (Elan =?utf-8?q?Ruusam=C3=A4e?=)
Date: Sun, 20 Jul 2008 12:58:50 +0300
Subject: PLD-specs-TODO
In-Reply-To: <200806161615.10950.witek.firlej@gmail.com>
References: <200805231803.52904.kamil.listy@klecza.pl>
	<200806152123.26811.witek.firlej@gmail.com>
	<200806161615.10950.witek.firlej@gmail.com>
Message-ID: <200807201258.50596.glen@delfi.ee>

On Monday 16 June 2008 17:15, Witek Firlej wrote:
> Ok... now it's look better.
>
> I'll give info on pld-users main page, and on forum.

there's one problem. the changes aren't notified to pld lists.
should be notified to pld-cvs-commit at lists.pld-linux.org like main wiki page 
is.

config change would be sth like this:

// send change info to this email (leave blank for nobody)
./local.php:$conf['notify']      = 'pld-cvs-commit at lists.pld-linux.org';

-- 
glen


From glen at pld-linux.org  Mon Jul 21 10:59:20 2008
From: glen at pld-linux.org (Elan =?iso-8859-1?q?Ruusam=E4e?=)
Date: Mon, 21 Jul 2008 11:59:20 +0300
Subject: permission of /home/services
Message-ID: <200807211159.20293.glen@pld-linux.org>

why it's non readable for everybody:
drwxr-x--x 11 root adm 124 2008-05-28 05:48 /home/services/
?

as i have uid=builder $HOME=/home/services/builder (as i consider it service, not real user).

however such parent dir permission causes some weird problems like:

1.
+ /usr/bin/perl Build.PL destdir=/tmp/B.f3367d/perl-Algorithm-C3-0.07-root-builder installdirs=vendor
/bin/pwd: cannot open directory `../../../..': Permission denied
/bin/pwd: cannot open directory `../../../..': Permission denied
Can't find file lib/Algorithm/C3.pm to determine version at /usr/share/perl5/vendor_perl/Module/Build/Base.pm line 950.
error: Bad exit status from /tmp/B.f3367d/rpm-tmp.79438 (%build)

2.
sudo / su fail with "can't open session" if terminal not attached (ran from cron)

3.
+ /usr/bin/make -j1 -C /usr/src/linux prepare scripts HOSTCC=alpha-pld-linux-gcc SYSSRC=/usr/src/linux SYSOUT=/home/services/builder/rpm/BUILD/svgalib-1.9.25/kernel/svgalib_helper/o 
O=/home/services/builder/rpm/BUILD/svgalib-1.9.25/kernel/svgalib_helper/o CC=alpha-pld-linux-gcc
/bin/pwd: cannot open directory `../../../../../../..': Permission denied
make: Entering directory `/usr/src/linux-2.6.22.19'
Makefile:116: *** output directory "/home/services/builder/rpm/BUILD/svgalib-1.9.25/kernel/svgalib_helper/o" does not exist.  Stop.
make: Leaving directory `/usr/src/linux-2.6.22.19'
error: Bad exit status from /tmp/B.e0971b/rpm-tmp.17143 (%build)

i've tracked down the changes regarding this path, and it's always been 751 without much description why:

http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/SPECS/FHS.spec.diff?r1=1.85;r2=1.86;f=h djurban: revert my bogus changes, group of services set to adm (751,root,adm)
http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/SPECS/FHS.spec.diff?r1=1.83;r2=1.84;f=h djurban: add services group for /home/services, this was driving me crazy (751,root,services)
http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/SPECS/FHS.spec.diff?r1=1.79;r2=1.80;f=h deejay1: readded /home/services (751,root,root)
http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/SPECS/FHS.spec.diff?r1=1.76;r2=1.77;f=h averne: FHS 2.3 compilant (removed /home/services without a notice)
http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/SPECS/FHS.spec.diff?r1=1.36;r2=1.37;f=h qboosh: added /home/services directory (751,root,root)

my suggestion is to change it to 755,root,root as i don't see much gain other than security by obscurity
and adding builder user to adm group i don't want to do either. assuming home dir of 'service' should be /home/services.

-- 
glen


From hawk at limanowa.net  Mon Jul 21 12:14:51 2008
From: hawk at limanowa.net (Marcin Krol)
Date: Mon, 21 Jul 2008 12:14:51 +0200
Subject: permission of /home/services
In-Reply-To: <200807211159.20293.glen@pld-linux.org>
References: <200807211159.20293.glen@pld-linux.org>
Message-ID: <4884619B.8040709@limanowa.net>

> my suggestion is to change it to 755,root,root as i don't see much gain other than security by obscurity
> and adding builder user to adm group i don't want to do either. assuming home dir of 'service' should be /home/services.

I'm happy with current permissions as I don't need to chmod every 
directory in /home/services by hand. As for your problems, I usually 
'chmod 711 /home/users' and never had problems with building packges or 
with su/sudo.

M.


From sls at poczta.wp.pl  Mon Jul 21 12:34:44 2008
From: sls at poczta.wp.pl (Szymon Siwek)
Date: Mon, 21 Jul 2008 12:34:44 +0200
Subject: permission of /home/services
In-Reply-To: <200807211159.20293.glen@pld-linux.org>
References: <200807211159.20293.glen@pld-linux.org>
Message-ID: <20080721103444.GA11763@cion.siwster.com>

On Mon, Jul 21, 2008 at 11:59:20AM +0300, Elan Ruusam?e wrote:
> why it's non readable for everybody:
> drwxr-x--x 11 root adm 124 2008-05-28 05:48 /home/services/
> ?
> 
I have similiar question about /srv

> my suggestion is to change it to 755,root,root as i don't see much gain other than security by obscurity
> 
...and similar suggestion about /srv

-- 
Szymon Siwek


From sls at poczta.wp.pl  Mon Jul 21 12:37:17 2008
From: sls at poczta.wp.pl (Szymon Siwek)
Date: Mon, 21 Jul 2008 12:37:17 +0200
Subject: SPECS: gcc.spec rel 3; include ecj here; patch by uzi18/o2.pl
In-Reply-To: <SPECS_gcc.spec.1.549@pld-linux.org>
References: <SPECS_gcc.spec.1.548@pld-linux.org>
	<SPECS_gcc.spec.1.549@pld-linux.org>
Message-ID: <20080721103717.GD11763@cion.siwster.com>

On Sun, Jul 20, 2008 at 01:10:35PM +0200, arekm wrote:
> Author: arekm                        Date: Sun Jul 20 11:10:35 2008 GMT
> Module: SPECS                         Tag: HEAD
> ---- Log message:
> rel 3; include ecj here; patch by uzi18/o2.pl
> 
> ---- Files affected:
> SPECS:
>    gcc.spec (1.548 -> 1.549) 
> 
> @@ -128,6 +132,7 @@
>  BuildRequires:	gtk+2-devel >= 2:2.4.0
>  BuildRequires:	libart_lgpl-devel
>  BuildRequires:	pango-devel
> +BuildRequires:	readline-devel 
>  BuildRequires:	xorg-lib-libXtst-devel
>  %endif
>  %if %{with qt}

To pewne? Mi si? budowa?o bez readlina.

-- 
Szymon Siwek
"Nikt nie jest zadowolny ze swojej fortuny, 
za to ka?dy - ze swego rozumu" -- Franciszek de La Rochefoucauld


From gotar at polanet.pl  Mon Jul 21 13:11:53 2008
From: gotar at polanet.pl (Tomasz Pala)
Date: Mon, 21 Jul 2008 13:11:53 +0200
Subject: permission of /home/services
In-Reply-To: <20080721103444.GA11763@cion.siwster.com>
References: <200807211159.20293.glen@pld-linux.org>
	<20080721103444.GA11763@cion.siwster.com>
Message-ID: <20080721111153.GA4882@pepin.polanet.pl>

On Mon, Jul 21, 2008 at 12:34:44 +0200, Szymon Siwek wrote:

>> why it's non readable for everybody:
>> drwxr-x--x 11 root adm 124 2008-05-28 05:48 /home/services/
>> ?
>> 
> I have similiar question about /srv

/home/services/ listing is available via /etc/passwd, while /srv is not.

>> my suggestion is to change it to 755,root,root as i don't see much gain other than security by obscurity
>> 
> ...and similar suggestion about /srv

One may not wish to expose what services are running on the system (may
not apply to /h/s/).

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


From glen at pld-linux.org  Mon Jul 21 13:13:08 2008
From: glen at pld-linux.org (Elan =?iso-8859-1?q?Ruusam=E4e?=)
Date: Mon, 21 Jul 2008 14:13:08 +0300
Subject: permission of /home/services
In-Reply-To: <4884619B.8040709@limanowa.net>
References: <200807211159.20293.glen@pld-linux.org>
	<4884619B.8040709@limanowa.net>
Message-ID: <200807211413.08235.glen@pld-linux.org>

On Monday 21 July 2008 13:14:51 Marcin Krol wrote:
> > my suggestion is to change it to 755,root,root as i don't see much gain
> > other than security by obscurity and adding builder user to adm group i
> > don't want to do either. assuming home dir of 'service' should be
> > /home/services.
>
> I'm happy with current permissions as I don't need to chmod every
> directory in /home/services by hand. As for your problems, I usually
> 'chmod 711 /home/users' and never had problems with building packges or
> with su/sudo.

my problem is opposite, the restrictive permissions cause havoc with programs 
expecting to readdir(), getcwd() or sth similar to succeeed.

and doing chmod on directory from rpm package, will make the permissions lost 
again if the owner package is upgraded. this is not consistent behaviour.

-- 
glen


From hawk at limanowa.net  Mon Jul 21 13:39:34 2008
From: hawk at limanowa.net (Marcin Krol)
Date: Mon, 21 Jul 2008 13:39:34 +0200
Subject: permission of /home/services
In-Reply-To: <200807211413.08235.glen@pld-linux.org>
References: <200807211159.20293.glen@pld-linux.org>	<4884619B.8040709@limanowa.net>
	<200807211413.08235.glen@pld-linux.org>
Message-ID: <48847576.4090302@limanowa.net>

> and doing chmod on directory from rpm package, will make the permissions lost 
> again if the owner package is upgraded. this is not consistent behaviour.

This can be prevented with %_netsharedpath. I'm using it ie. for 
/var/mail where our distribution default permissions prevent creation of 
new mailboxes.

M.


From glen at pld-linux.org  Mon Jul 21 14:52:44 2008
From: glen at pld-linux.org (Elan =?iso-8859-1?q?Ruusam=E4e?=)
Date: Mon, 21 Jul 2008 15:52:44 +0300
Subject: permission of /home/services
In-Reply-To: <48847576.4090302@limanowa.net>
References: <200807211159.20293.glen@pld-linux.org>
	<200807211413.08235.glen@pld-linux.org>
	<48847576.4090302@limanowa.net>
Message-ID: <200807211552.44157.glen@pld-linux.org>

On Monday 21 July 2008 14:39:34 Marcin Krol wrote:
> > and doing chmod on directory from rpm package, will make the permissions
> > lost again if the owner package is upgraded. this is not consistent
> > behaviour.
>
> This can be prevented with %_netsharedpath. I'm using it ie. for
> /var/mail where our distribution default permissions prevent creation of
> new mailboxes.

this will also prevent creating subdirectories underneath it 
(/home/services/apache/html, /home/services/apache/cgi-bin)

so this is still not the way.

if there's no real reason behind 711,root,adm permission i'd vote for 
755,root,root (don't tell it's security is the reason, one can easily probe 
existence of directories from there as most of these dirs came from distro 
rpm packages).

-- 
glen


From qboosh at pld-linux.org  Mon Jul 21 17:53:48 2008
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Mon, 21 Jul 2008 17:53:48 +0200
Subject: permission of /home/services
In-Reply-To: <4884619B.8040709@limanowa.net>
References: <200807211159.20293.glen@pld-linux.org>
	<4884619B.8040709@limanowa.net>
Message-ID: <20080721155348.GA16773@stranger.qboosh.pl>

On Mon, Jul 21, 2008 at 12:14:51PM +0200, Marcin Krol wrote:
> > my suggestion is to change it to 755,root,root as i don't see much gain other than security by obscurity
> > and adding builder user to adm group i don't want to do either. assuming home dir of 'service' should be /home/services.
> 
> I'm happy with current permissions as I don't need to chmod every 
> directory in /home/services by hand.

???


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


From qboosh at pld-linux.org  Mon Jul 21 18:01:30 2008
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Mon, 21 Jul 2008 18:01:30 +0200
Subject: permission of /home/services
In-Reply-To: <200807211159.20293.glen@pld-linux.org>
References: <200807211159.20293.glen@pld-linux.org>
Message-ID: <20080721160130.GB16773@stranger.qboosh.pl>

On Mon, Jul 21, 2008 at 11:59:20AM +0300, Elan Ruusam?e wrote:
> why it's non readable for everybody:
> drwxr-x--x 11 root adm 124 2008-05-28 05:48 /home/services/
> ?
> 
> as i have uid=builder $HOME=/home/services/builder (as i consider it service, not real user).
> 
> however such parent dir permission causes some weird problems like:
> 
> 1.
> + /usr/bin/perl Build.PL destdir=/tmp/B.f3367d/perl-Algorithm-C3-0.07-root-builder installdirs=vendor
> /bin/pwd: cannot open directory `../../../..': Permission denied
> /bin/pwd: cannot open directory `../../../..': Permission denied
> Can't find file lib/Algorithm/C3.pm to determine version at /usr/share/perl5/vendor_perl/Module/Build/Base.pm line 950.
> error: Bad exit status from /tmp/B.f3367d/rpm-tmp.79438 (%build)
> 
> 2.
> sudo / su fail with "can't open session" if terminal not attached (ran from cron)
> 
> 3.
> + /usr/bin/make -j1 -C /usr/src/linux prepare scripts HOSTCC=alpha-pld-linux-gcc SYSSRC=/usr/src/linux SYSOUT=/home/services/builder/rpm/BUILD/svgalib-1.9.25/kernel/svgalib_helper/o 
> O=/home/services/builder/rpm/BUILD/svgalib-1.9.25/kernel/svgalib_helper/o CC=alpha-pld-linux-gcc
> /bin/pwd: cannot open directory `../../../../../../..': Permission denied
> make: Entering directory `/usr/src/linux-2.6.22.19'
> Makefile:116: *** output directory "/home/services/builder/rpm/BUILD/svgalib-1.9.25/kernel/svgalib_helper/o" does not exist.  Stop.
> make: Leaving directory `/usr/src/linux-2.6.22.19'
> error: Bad exit status from /tmp/B.e0971b/rpm-tmp.17143 (%build)
> 
> i've tracked down the changes regarding this path, and it's always been 751 without much description why:
> 
> http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/SPECS/FHS.spec.diff?r1=1.85;r2=1.86;f=h djurban: revert my bogus changes, group of services set to adm (751,root,adm)
> http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/SPECS/FHS.spec.diff?r1=1.83;r2=1.84;f=h djurban: add services group for /home/services, this was driving me crazy (751,root,services)
> http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/SPECS/FHS.spec.diff?r1=1.79;r2=1.80;f=h deejay1: readded /home/services (751,root,root)
> http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/SPECS/FHS.spec.diff?r1=1.76;r2=1.77;f=h averne: FHS 2.3 compilant (removed /home/services without a notice)
> http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/SPECS/FHS.spec.diff?r1=1.36;r2=1.37;f=h qboosh: added /home/services directory (751,root,root)
> 
> my suggestion is to change it to 755,root,root as i don't see much gain other than security by obscurity
> and adding builder user to adm group i don't want to do either. assuming home dir of 'service' should be /home/services.

First track down what is the real problem with pwd. I don't see such
issues with coreutils 6.10 and glibc 2.8. Broken libc on alpha?
Changing permissions would be just hiding it.


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


From hawk at limanowa.net  Tue Jul 22 08:48:09 2008
From: hawk at limanowa.net (Marcin Krol)
Date: Tue, 22 Jul 2008 08:48:09 +0200
Subject: permission of /home/services
In-Reply-To: <20080721155348.GA16773@stranger.qboosh.pl>
References: <200807211159.20293.glen@pld-linux.org>	<4884619B.8040709@limanowa.net>
	<20080721155348.GA16773@stranger.qboosh.pl>
Message-ID: <488582A9.8060205@limanowa.net>

> ???

Just some of my old habits, nothing to worry about.

M.


From glen at pld-linux.org  Tue Jul 22 09:05:02 2008
From: glen at pld-linux.org (Elan =?utf-8?q?Ruusam=C3=A4e?=)
Date: Tue, 22 Jul 2008 10:05:02 +0300
Subject: SPECS: seamonkey.spec - _noauto* cleanup: don't provide any
	private libs or...
In-Reply-To: <SPECS_seamonkey.spec.1.88@pld-linux.org>
References: <SPECS_seamonkey.spec.1.87@pld-linux.org>
	<SPECS_seamonkey.spec.1.88@pld-linux.org>
Message-ID: <200807221005.03302.glen@pld-linux.org>

On Tuesday 22 July 2008 00:07, qboosh wrote:
> +%define????????????????_noautoreq??????libgfxpsshar.so libgkgfx.so
> libgtkembedmoz.so libgtkxtbin.so libjsj.so libldap50.so libmozjs.so
> libprldap50.so libssldap50.so

this sounds like it should use external mozldap

-- 
glen


From glen at pld-linux.org  Tue Jul 22 09:16:43 2008
From: glen at pld-linux.org (Elan =?iso-8859-1?q?Ruusam=E4e?=)
Date: Tue, 22 Jul 2008 10:16:43 +0300
Subject: permission of /home/services
In-Reply-To: <20080721160130.GB16773@stranger.qboosh.pl>
References: <200807211159.20293.glen@pld-linux.org>
	<20080721160130.GB16773@stranger.qboosh.pl>
Message-ID: <200807221016.43367.glen@pld-linux.org>

On Monday 21 July 2008 19:01, Jakub Bogusz wrote:
> First track down what is the real problem with pwd. I don't see such
> issues with coreutils 6.10 and glibc 2.8. Broken libc on alpha?
> Changing permissions would be just hiding it.

a side note: ever tried 711 on / ?
a lot of apps broke.

-- 
glen


From qboosh at pld-linux.org  Tue Jul 22 18:32:07 2008
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Tue, 22 Jul 2008 18:32:07 +0200
Subject: permission of /home/services
In-Reply-To: <200807221016.43367.glen@pld-linux.org>
References: <200807211159.20293.glen@pld-linux.org>
	<20080721160130.GB16773@stranger.qboosh.pl>
	<200807221016.43367.glen@pld-linux.org>
Message-ID: <20080722163207.GA29408@stranger.qboosh.pl>

On Tue, Jul 22, 2008 at 10:16:43AM +0300, Elan Ruusam?e wrote:
> On Monday 21 July 2008 19:01, Jakub Bogusz wrote:
> > First track down what is the real problem with pwd. I don't see such
> > issues with coreutils 6.10 and glibc 2.8. Broken libc on alpha?
> > Changing permissions would be just hiding it.
> 
> a side note: ever tried 711 on / ?
> a lot of apps broke.

I didn't catch anything that would prevent me from using cron or building
packages then.


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


From qboosh at pld-linux.org  Wed Jul 23 17:23:43 2008
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Wed, 23 Jul 2008 17:23:43 +0200
Subject: SOURCES: kde4-kdelibs-findboost.patch (NEW) - help finding
	boost - fixes kd...
In-Reply-To: <SOURCES_kde4_kdelibs_findboost.patch.1.1@pld-linux.org>
References: <SOURCES_kde4_kdelibs_findboost.patch.NONE@pld-linux.org>
	<SOURCES_kde4_kdelibs_findboost.patch.1.1@pld-linux.org>
Message-ID: <20080723152343.GA19059@stranger.qboosh.pl>

On Wed, Jul 23, 2008 at 11:59:54AM +0200, shadzik wrote:
> Author: shadzik                      Date: Wed Jul 23 09:59:54 2008 GMT
> Module: SOURCES                       Tag: HEAD
> ---- Log message:
> - help finding boost
> - fixes kdesdk umbrella build

> +@@ -211,12 +211,15 @@
> +     # cdrom inserted it will popup a very annoying dialog
> +     #D:/boost/include
> +     /sw/local/include
> ++    /usr/include
> +   )
> + 
> +   SET(_boost_LIBRARIES_SEARCH_DIRS
> +     C:/boost/lib
> +     "C:/Program Files/boost/boost_${Boost_MINIMUM_VERSION}/lib"
> +     /sw/local/lib
> ++    /usr/lib
> ++    /usr/lib64

Likely to break on 64-bit build in multilib environment.
Should use only libdir suitable for selected target.


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


From qboosh at pld-linux.org  Wed Jul 23 17:27:41 2008
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Wed, 23 Jul 2008 17:27:41 +0200
Subject: PLDWWW: ThInfo
In-Reply-To: <20080723125949.19679.52951@www>
References: <20080723125949.19679.52951@www>
Message-ID: <20080723152740.GB19059@stranger.qboosh.pl>

On Wed, Jul 23, 2008 at 12:59:49PM -0000, grizz  wrote:
> Author: grizz   Date: Wed Jul 23 12:59:49 2008 GMT
> Module: PLDWWW   URL: http://pld-linux.org/ThInfo?action=diff&rev2=13&rev1=12
> ---- Log message:
> Hot new things, were quite old ;)

However I'd leave a note about lzma RPMs (just without "hot news"
header).


>   
> - === Hot new things ===
> - 
> - Th contains, among many other, the following fresh packages:
> - 
> -  * gcc 4.2
> -  * xorg 7.2 with [http://team.pld-linux.org/~wolf/xglpld.png Xgl and compiz]
> - 
> - RPM packages are compressed using LZMA, which results in both substantially smaller file sizes and faster decompression
> - 


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


From glen at pld-linux.org  Thu Jul 24 16:10:56 2008
From: glen at pld-linux.org (Elan =?utf-8?q?Ruusam=C3=A4e?=)
Date: Thu, 24 Jul 2008 17:10:56 +0300
Subject: SPECS: perl-MIME-Lite.spec - reverted - moved to DEVEL (there's
	no required...
In-Reply-To: <SPECS_perl_MIME_Lite.spec.1.45@pld-linux.org>
References: <SPECS_perl_MIME_Lite.spec.1.44@pld-linux.org>
	<SPECS_perl_MIME_Lite.spec.1.45@pld-linux.org>
Message-ID: <200807241710.56488.glen@pld-linux.org>

On Thursday 24 July 2008 16:23:22 gotar wrote:
> Author: gotar                        Date: Thu Jul 24 13:23:22 2008 GMT
> Module: SPECS                         Tag: HEAD
> ---- Log message:
> - reverted - moved to DEVEL (there's no required Email-Date-Format in PLD)
>
> ---- Files affected:
> SPECS:
>    perl-MIME-Lite.spec (1.44 -> 1.45)

why not add it?

-- 
glen


From gotar at polanet.pl  Thu Jul 24 17:26:54 2008
From: gotar at polanet.pl (Tomasz Pala)
Date: Thu, 24 Jul 2008 17:26:54 +0200
Subject: SPECS: perl-MIME-Lite.spec - reverted - moved to DEVEL (there's
	no required...
In-Reply-To: <200807241710.56488.glen@pld-linux.org>
References: <SPECS_perl_MIME_Lite.spec.1.44@pld-linux.org>
	<SPECS_perl_MIME_Lite.spec.1.45@pld-linux.org>
	<200807241710.56488.glen@pld-linux.org>
Message-ID: <20080724152654.GA28507@pepin.polanet.pl>

On Thu, Jul 24, 2008 at 17:10:56 +0300, Elan Ruusam?e wrote:

>> - reverted - moved to DEVEL (there's no required Email-Date-Format in PLD)
>>
>> ---- Files affected:
>> SPECS:
>>    perl-MIME-Lite.spec (1.44 -> 1.45)
> 
> why not add it?

ENOTIME
used from cpan, meanwhile DEVEL is ready and waiting for missing spec.

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


From glen at delfi.ee  Thu Jul 24 20:11:30 2008
From: glen at delfi.ee (Elan =?iso-8859-2?q?Ruusam=E4e?=)
Date: Thu, 24 Jul 2008 21:11:30 +0300
Subject: SPECS: perl-MIME-Lite.spec - reverted - moved to DEVEL (there's
	no required...
In-Reply-To: <20080724152654.GA28507@pepin.polanet.pl>
References: <SPECS_perl_MIME_Lite.spec.1.44@pld-linux.org>
	<200807241710.56488.glen@pld-linux.org>
	<20080724152654.GA28507@pepin.polanet.pl>
Message-ID: <200807242111.30697.glen@delfi.ee>

On Thursday 24 July 2008 18:26, Tomasz Pala wrote:
> On Thu, Jul 24, 2008 at 17:10:56 +0300, Elan Ruusam?e wrote:
> >> - reverted - moved to DEVEL (there's no required Email-Date-Format in
> >> PLD)
> >>
> >> ---- Files affected:
> >> SPECS:
> >>    perl-MIME-Lite.spec (1.44 -> 1.45)
> >
> > why not add it?
>
> ENOTIME
> used from cpan, meanwhile DEVEL is ready and waiting for missing spec.

eh damn. the perl spec making is easy.

glen at builder-ac pld/SPECS $ date
Thu Jul 24 21:05:57 EEST 2008

glen at builder-ac pld/SPECS $ pldcpan Email::Date::Format

... testing, building, adapterizing
... figuring out the spec really exists already
... merging with my produced one

glen at builder-ac pld/SPECS $ date
Thu Jul 24 21:10:27 EEST 2008


-- 
glen


From gotar at polanet.pl  Fri Jul 25 01:54:45 2008
From: gotar at polanet.pl (Tomasz Pala)
Date: Fri, 25 Jul 2008 01:54:45 +0200
Subject: SPECS: perl-MIME-Lite.spec - reverted - moved to DEVEL (there's
	no required...
In-Reply-To: <200807242111.30697.glen@delfi.ee>
References: <SPECS_perl_MIME_Lite.spec.1.44@pld-linux.org>
	<200807241710.56488.glen@pld-linux.org>
	<20080724152654.GA28507@pepin.polanet.pl>
	<200807242111.30697.glen@delfi.ee>
Message-ID: <20080724235445.GA3499@pepin.polanet.pl>

On Thu, Jul 24, 2008 at 21:11:30 +0300, Elan Ruusam?e wrote:

> eh damn. the perl spec making is easy.

But writing %desc is not. I've taken perl-Email-Date as template and
made it in a few minutes (compare timestamp of my previous mail with
commit) - without it I wouldn't bother.

> glen at builder-ac pld/SPECS $ pldcpan Email::Date::Format
> 
> ... testing, building, adapterizing
> ... figuring out the spec really exists already
> ... merging with my produced one

And just tell me - what was the point of adding:

1. %bcond_without autodeps (removed already)
2. %{_mandir}/man3/* having no files at all?

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


From glen at delfi.ee  Fri Jul 25 08:01:41 2008
From: glen at delfi.ee (Elan =?iso-8859-2?q?Ruusam=E4e?=)
Date: Fri, 25 Jul 2008 09:01:41 +0300
Subject: SPECS: perl-MIME-Lite.spec - reverted - moved to DEVEL (there's
	no required...
In-Reply-To: <20080724235445.GA3499@pepin.polanet.pl>
References: <SPECS_perl_MIME_Lite.spec.1.44@pld-linux.org>
	<200807242111.30697.glen@delfi.ee>
	<20080724235445.GA3499@pepin.polanet.pl>
Message-ID: <200807250901.42570.glen@delfi.ee>

On Friday 25 July 2008 02:54, Tomasz Pala wrote:
> And just tell me - what was the point of adding:
>
> 1. %bcond_without autodeps (removed already)
we have no policy, i tought it would be cool to have unifed perl packages header with autodeps/tests bconds.

> 2. %{_mandir}/man3/* having no files at all?
what you mean? i do have file(s) there.

glen at builder-ac pld/SPECS $ rpm -qpl /home/glen/rpm/pld/RPMS/perl-Email-Date-Format-1.002-1.noarch.rpm
/usr/share/doc/perl-Email-Date-Format-1.002
/usr/share/doc/perl-Email-Date-Format-1.002/Changes.gz
/usr/share/doc/perl-Email-Date-Format-1.002/README.gz
/usr/share/man/man3/Email::Date::Format.3pm.gz
/usr/share/perl5/vendor_perl/Email/Date
/usr/share/perl5/vendor_perl/Email/Date/Format.pm

-- 
glen


From gotar at polanet.pl  Fri Jul 25 12:10:39 2008
From: gotar at polanet.pl (Tomasz Pala)
Date: Fri, 25 Jul 2008 12:10:39 +0200
Subject: SPECS: perl-MIME-Lite.spec - reverted - moved to DEVEL (there's
	no required...
In-Reply-To: <200807250901.42570.glen@delfi.ee>
References: <SPECS_perl_MIME_Lite.spec.1.44@pld-linux.org>
	<200807242111.30697.glen@delfi.ee>
	<20080724235445.GA3499@pepin.polanet.pl>
	<200807250901.42570.glen@delfi.ee>
Message-ID: <20080725101038.GA9453@pepin.polanet.pl>

On Fri, Jul 25, 2008 at 09:01:41 +0300, Elan Ruusam?e wrote:

> > 1. %bcond_without autodeps (removed already)
> we have no policy, i tought it would be cool to have unifed perl packages header with autodeps/tests bconds.

Hmmm...
$  grep ^%bcond perl* | grep autodeps | wc -l
66

$  grep -v ^%bcond perl* | grep 'with autodeps' | wc -l
63

It doesn't seem to be well-spreaded, and if we want to use it it's even
better not to have this line in file when not really used - one can
simply grep to find out where it's done and where it's not.


$  grep -v ^%bcond perl* | grep 'with autodeps' | cut -f1 -d: | sort > with_autodeps
$  grep ^%bcond perl* | grep autodeps | cut -f1 -d: | sort > bcond_autodeps

$  diff bcond_autodeps with_autodeps | grep perl
> perl-Audio-CoolEdit.spec
< perl-Class-C3-XS.spec
> perl-Data-Serializer.spec
< perl-debug.spec
< perl-Gearman-Server.spec
< perl-IO-BufferedSelect.spec
< perl-Mail-SPF.spec
< perl-MogileFS-Server.spec
> perl-Net-IDN-Nameprep.spec
< perl-Python-Bytecode.spec
< perl-WWW-RobotRules-Parser.spec
> perl-XML-Dumper.spec
> perl-XML-SAX-Expat-Incremental.spec

I've just fixed specs with no bcond definition and, well... removed empty
bconds from left-hand list.

BTW
1. all of the 'right-hand' have make install not pure_install - what's the difference?
2. pldcpan seems to create spec with newline at the end - it shouldn't.
3. how one can do this in svn-like repo?

> > 2. %{_mandir}/man3/* having no files at all?
> what you mean? i do have file(s) there.

Haven't noticed creating them.

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


From udvzsolt at gmail.com  Fri Jul 25 12:59:49 2008
From: udvzsolt at gmail.com (Zsolt Udvari)
Date: Fri, 25 Jul 2008 10:59:49 +0000
Subject: SPEC files - newsbeuter and one of its depends: stfl
Message-ID: <760ece280807250359u58f74dbdre5a313a2e45fd2c@mail.gmail.com>

Hi all!

I'm using a console-based newsreader, newsbeuter and there isn't in
pld's repo. So I've created spec-file for newsbeuter and stfl (one of
its depends).

http://udvzsolt.extra.hu/tmp/spec/stfl.spec
http://udvzsolt.extra.hu/tmp/spec/newsbeuter.spec


From adamg at biomerieux.pl  Fri Jul 25 13:39:47 2008
From: adamg at biomerieux.pl (Adam =?utf-8?B?R2/FgsSZYmlvd3NraQ==?=)
Date: Fri, 25 Jul 2008 13:39:47 +0200
Subject: SPEC files - newsbeuter and one of its depends: stfl
In-Reply-To: <760ece280807250359u58f74dbdre5a313a2e45fd2c@mail.gmail.com>
References: <760ece280807250359u58f74dbdre5a313a2e45fd2c@mail.gmail.com>
Message-ID: <20080725113947.GA8074@mysza.eu.org>

On Fri, Jul 25, 2008 at 10:59:49AM +0000, Zsolt Udvari wrote:
> Hi all!
> 
> I'm using a console-based newsreader, newsbeuter and there isn't in
> pld's repo. So I've created spec-file for newsbeuter and stfl (one of
> its depends).

I added them into CVS, thanks for the contribution. 

These specs need some work though, you may wish to track changes made to
those files.

-- 
 http://www.mysza.eu.org/ | Everybody needs someone sure, someone true,
   PLD Linux developer    | Everybody needs some solid rock, I know I do.


From glen at pld-linux.org  Fri Jul 25 14:57:26 2008
From: glen at pld-linux.org (Elan =?iso-8859-1?q?Ruusam=E4e?=)
Date: Fri, 25 Jul 2008 15:57:26 +0300
Subject: suggests in dist that don't exist
Message-ID: <200807251557.26863.glen@pld-linux.org>

perhaps remove such suggests that don't exist?

some upgrade-dist on th-i686:

Installing set #13
Processing dependencies...
mailcap-2.1.14-13.noarch obsoleted by mailcap-2.2-3.noarch
warn: mailcap-2.2-3.noarch: suggested flash not found, skipped
warn: mailcap-2.2-3.noarch: suggested mikmod not found, skipped
warn: mailcap-2.2-3.noarch: suggested soffice2html not found, skipped
warn: mailcap-2.2-3.noarch: suggested xlhtml not found, skipped
Package mailcap-2.2-3.noarch suggests installation of:
1. colordiff
2. elinks
3. eog
4. gv
5. metamail
6. odt2txt
7. qiv
8. wv
9. xdvi
10. xpdf
11. xpdf-tools
Try to install them? (y - all, n - nothing, s - select some of)? [N/y/s]

-- 
glen


From glen at pld-linux.org  Fri Jul 25 14:58:44 2008
From: glen at pld-linux.org (Elan =?iso-8859-2?q?Ruusam=E4e?=)
Date: Fri, 25 Jul 2008 15:58:44 +0300
Subject: SPECS: perl-MIME-Lite.spec - reverted - moved to DEVEL (there's
	no required...
In-Reply-To: <20080725101038.GA9453@pepin.polanet.pl>
References: <SPECS_perl_MIME_Lite.spec.1.44@pld-linux.org>
	<200807250901.42570.glen@delfi.ee>
	<20080725101038.GA9453@pepin.polanet.pl>
Message-ID: <200807251558.45002.glen@pld-linux.org>

On Friday 25 July 2008 13:10:39 Tomasz Pala wrote:
> 1. all of the 'right-hand' have make install not pure_install - what's the
> difference?

pure_install doesn't create perlocal.pod or .packlist (don't remember which 
one exactly)

-- 
glen


From gotar at polanet.pl  Fri Jul 25 15:13:09 2008
From: gotar at polanet.pl (Tomasz Pala)
Date: Fri, 25 Jul 2008 15:13:09 +0200
Subject: suggests in dist that don't exist
In-Reply-To: <200807251557.26863.glen@pld-linux.org>
References: <200807251557.26863.glen@pld-linux.org>
Message-ID: <20080725131309.GA1712@pepin.polanet.pl>

On Fri, Jul 25, 2008 at 15:57:26 +0300, Elan Ruusam?e wrote:

> perhaps remove such suggests that don't exist?

They all exist.

> some upgrade-dist on th-i686:
> 
> Installing set #13
> Processing dependencies...
> mailcap-2.1.14-13.noarch obsoleted by mailcap-2.2-3.noarch
> warn: mailcap-2.2-3.noarch: suggested flash not found, skipped

flash is obsoleted by gplflash - fixed.

> warn: mailcap-2.2-3.noarch: suggested mikmod not found, skipped
> warn: mailcap-2.2-3.noarch: suggested soffice2html not found, skipped
> warn: mailcap-2.2-3.noarch: suggested xlhtml not found, skipped

Just STBR.

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


From patrys at pld-linux.org  Fri Jul 25 15:27:58 2008
From: patrys at pld-linux.org (Patryk Zawadzki)
Date: Fri, 25 Jul 2008 15:27:58 +0200
Subject: kernel + xorg + nvidia
Message-ID: <89b6ba3a0807250627l4ef0dc54m633513e796491f7f@mail.gmail.com>

Currently (as of glen's commit) the kernel module requires a proper
version of the userspace Xorg driver. The two problems I see:

* the real requirement is the other way around - it's xorg that needs
the kernel module loaded
* it forces users to uninstall nvidia modules from older kernels in
order to install a new kernel (as opposed to upgrading)

Therefore I propose we reverse the requirement:

* have xorg-driver-video-nvidia require kernel-module(nvidia) = %{version}
* have kernel*-video-nvidia provide kernel-module(nvidia) = %{version}

-- 
Patryk Zawadzki
PLD Linux Distribution


From glen at pld-linux.org  Fri Jul 25 15:38:52 2008
From: glen at pld-linux.org (Elan =?iso-8859-2?q?Ruusam=E4e?=)
Date: Fri, 25 Jul 2008 16:38:52 +0300
Subject: suggests in dist that don't exist
In-Reply-To: <20080725131309.GA1712@pepin.polanet.pl>
References: <200807251557.26863.glen@pld-linux.org>
	<20080725131309.GA1712@pepin.polanet.pl>
Message-ID: <200807251638.53301.glen@pld-linux.org>

On Friday 25 July 2008 16:13:09 Tomasz Pala wrote:
> On Fri, Jul 25, 2008 at 15:57:26 +0300, Elan Ruusam?e wrote:
> > perhaps remove such suggests that don't exist?
>
> They all exist.

...

> > warn: mailcap-2.2-3.noarch: suggested mikmod not found, skipped
> > warn: mailcap-2.2-3.noarch: suggested soffice2html not found, skipped
> > warn: mailcap-2.2-3.noarch: suggested xlhtml not found, skipped
>
> Just STBR.

i'm not th RM, neither i have added the Suggests lines.

-- 
glen


From kamil.listy at klecza.pl  Fri Jul 25 20:59:39 2008
From: kamil.listy at klecza.pl (Kamil Dziedzic)
Date: Fri, 25 Jul 2008 20:59:39 +0200
Subject: SPECS: xorg-driver-video-nvidia.spec - let kernel require
	userspace, so the...
In-Reply-To: <SPECS_xorg_driver_video_nvidia.spec.1.164@pld-linux.org>
References: <SPECS_xorg_driver_video_nvidia.spec.1.163@pld-linux.org>
	<SPECS_xorg_driver_video_nvidia.spec.1.164@pld-linux.org>
Message-ID: <200807252059.44168.kamil.listy@klecza.pl>

Dnia pi?tek 25 lipiec 2008, glen napisa?:
> Author: glen                         Date: Fri Jul 25 13:23:48 2008 GMT
> Module: SPECS                         Tag: HEAD
> @@ -264,8 +264,9 @@
>  cat << 'EOF'
>  NOTE: You must also install kernel module for this driver to work
>    kernel-video-nvidia-%{version}
> -  kernel-laptop-video-nvidia-%{version}
>    kernel-desktop-video-nvidia-%{version}
> +  kernel-laptop-video-nvidia-%{version}
> +  kernel-vanilla-video-nvidia-%{version}
>
>  Depending on which kernel brand you use.
>

Maybe instead note better will be Suggests? P: and S: 
kernel-module-video-nvidia?

AFAIR suggests by default are not used by rpm? Right?

-- 
Regards, Kamil Dziedzic
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: </mailman/pipermail/pld-devel-en/attachments/20080725/eb8f54f4/attachment.sig>

From wolf.pld at gmail.com  Fri Jul 25 21:13:09 2008
From: wolf.pld at gmail.com (Bartosz Taudul)
Date: Fri, 25 Jul 2008 21:13:09 +0200
Subject: kernel + xorg + nvidia
In-Reply-To: <89b6ba3a0807250627l4ef0dc54m633513e796491f7f@mail.gmail.com>
References: <89b6ba3a0807250627l4ef0dc54m633513e796491f7f@mail.gmail.com>
Message-ID: <20080725191309.GA30476@bajzel>

On Fri, Jul 25, 2008 at 03:27:58PM +0200, Patryk Zawadzki wrote:
> Therefore I propose we reverse the requirement:
> 
> * have xorg-driver-video-nvidia require kernel-module(nvidia) = %{version}
RTF devel-hints.

wolf
-- 
  Bartek   .  
  Taudul   :  
          .:....................................................................
w o l f @ p l d - l i n u x . o r g            .:. http://wolf.valkyrie.one.pl/


From patrys at pld-linux.org  Fri Jul 25 21:43:08 2008
From: patrys at pld-linux.org (Patryk Zawadzki)
Date: Fri, 25 Jul 2008 21:43:08 +0200
Subject: kernel + xorg + nvidia
In-Reply-To: <20080725191309.GA30476@bajzel>
References: <89b6ba3a0807250627l4ef0dc54m633513e796491f7f@mail.gmail.com>
	<20080725191309.GA30476@bajzel>
Message-ID: <89b6ba3a0807251243h736b27edl6eb5f2dc1b81c09c@mail.gmail.com>

On Fri, Jul 25, 2008 at 9:13 PM, Bartosz Taudul <wolf.pld at gmail.com> wrote:
> On Fri, Jul 25, 2008 at 03:27:58PM +0200, Patryk Zawadzki wrote:
>> Therefore I propose we reverse the requirement:
>>
>> * have xorg-driver-video-nvidia require kernel-module(nvidia) = %{version}
> RTF devel-hints.

If you're referring to not requiring kernel parts by userspace - both
are built from the same spec so there's no "I'm on custom kernel"
excuse.

-- 
Patryk Zawadzki
PLD Linux Distribution


From kamil.listy at klecza.pl  Fri Jul 25 23:44:35 2008
From: kamil.listy at klecza.pl (Kamil Dziedzic)
Date: Fri, 25 Jul 2008 23:44:35 +0200
Subject: SPECS: kvm.spec - don't require external qemu, doesn't make sense.
In-Reply-To: <200807090156.07887.glen@pld-linux.org>
References: <SPECS_kvm.spec.1.40@pld-linux.org>
	<SPECS_kvm.spec.1.41@pld-linux.org>
	<200807090156.07887.glen@pld-linux.org>
Message-ID: <200807252344.52247.kamil.listy@klecza.pl>

Dnia ?roda 09 lipiec 2008, Elan Ruusam?e napisa?:
> On Wednesday 09 July 2008 00:41, blues wrote:
> >  $Log$
> > +Revision 1.41  2008/07/08 21:41:32  blues
> > +- don't require external qemu, doesn't make sense.
>
> why so? the /usr/share part is common, binary from kvm is just patched.

No response = reverting.

-- 
Regards, Kamil Dziedzic
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: </mailman/pipermail/pld-devel-en/attachments/20080725/69515a5a/attachment.sig>

From qboosh at pld-linux.org  Fri Jul 25 21:48:14 2008
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Fri, 25 Jul 2008 21:48:14 +0200
Subject: kernel + xorg + nvidia
In-Reply-To: <89b6ba3a0807251243h736b27edl6eb5f2dc1b81c09c@mail.gmail.com>
References: <89b6ba3a0807250627l4ef0dc54m633513e796491f7f@mail.gmail.com>
	<20080725191309.GA30476@bajzel>
	<89b6ba3a0807251243h736b27edl6eb5f2dc1b81c09c@mail.gmail.com>
Message-ID: <20080725194814.GA14202@stranger.qboosh.pl>

On Fri, Jul 25, 2008 at 09:43:08PM +0200, Patryk Zawadzki wrote:
> On Fri, Jul 25, 2008 at 9:13 PM, Bartosz Taudul <wolf.pld at gmail.com> wrote:
> > On Fri, Jul 25, 2008 at 03:27:58PM +0200, Patryk Zawadzki wrote:
> >> Therefore I propose we reverse the requirement:
> >>
> >> * have xorg-driver-video-nvidia require kernel-module(nvidia) = %{version}
> > RTF devel-hints.
> 
> If you're referring to not requiring kernel parts by userspace - both
> are built from the same spec so there's no "I'm on custom kernel"
> excuse.

Both build parts (kernel and userspace) are optional, so there is.

And both parts could live in different roots.


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


From patrys at pld-linux.org  Fri Jul 25 21:57:12 2008
From: patrys at pld-linux.org (Patryk Zawadzki)
Date: Fri, 25 Jul 2008 21:57:12 +0200
Subject: kernel + xorg + nvidia
In-Reply-To: <20080725194814.GA14202@stranger.qboosh.pl>
References: <89b6ba3a0807250627l4ef0dc54m633513e796491f7f@mail.gmail.com>
	<20080725191309.GA30476@bajzel>
	<89b6ba3a0807251243h736b27edl6eb5f2dc1b81c09c@mail.gmail.com>
	<20080725194814.GA14202@stranger.qboosh.pl>
Message-ID: <89b6ba3a0807251257v1701ba21t38a755e45f4b3af5@mail.gmail.com>

On Fri, Jul 25, 2008 at 9:48 PM, Jakub Bogusz <qboosh at pld-linux.org> wrote:
> Both build parts (kernel and userspace) are optional, so there is.
>
> And both parts could live in different roots.

Last time I tried it didn't work inside vservers/kvm. Maybe it's
different now but still the current solution breaks multiple kernels
(two kernel modules require two different versions of the same
package).

-- 
Patryk Zawadzki
PLD Linux Distribution


From qboosh at pld-linux.org  Fri Jul 25 22:09:23 2008
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Fri, 25 Jul 2008 22:09:23 +0200
Subject: kernel + xorg + nvidia
In-Reply-To: <89b6ba3a0807251257v1701ba21t38a755e45f4b3af5@mail.gmail.com>
References: <89b6ba3a0807250627l4ef0dc54m633513e796491f7f@mail.gmail.com>
	<20080725191309.GA30476@bajzel>
	<89b6ba3a0807251243h736b27edl6eb5f2dc1b81c09c@mail.gmail.com>
	<20080725194814.GA14202@stranger.qboosh.pl>
	<89b6ba3a0807251257v1701ba21t38a755e45f4b3af5@mail.gmail.com>
Message-ID: <20080725200923.GB14202@stranger.qboosh.pl>

On Fri, Jul 25, 2008 at 09:57:12PM +0200, Patryk Zawadzki wrote:
> On Fri, Jul 25, 2008 at 9:48 PM, Jakub Bogusz <qboosh at pld-linux.org> wrote:
> > Both build parts (kernel and userspace) are optional, so there is.
> >
> > And both parts could live in different roots.
> 
> Last time I tried it didn't work inside vservers/kvm. Maybe it's
> different now

I think virtualization matters here, it could disallow access to devices;
simple chroot should work.

> but still the current solution breaks multiple kernels
> (two kernel modules require two different versions of the same
> package).

At least release should be dropped from kernel module R.
Anyway, I don't like hard kernel/userspace dependencies in any
direction - maybe it should be Conflicts (<%{version}, >%{version},
no release) or Suggests.


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


From glen at delfi.ee  Sat Jul 26 14:44:51 2008
From: glen at delfi.ee (Elan =?iso-8859-1?q?Ruusam=E4e?=)
Date: Sat, 26 Jul 2008 15:44:51 +0300
Subject: kernel + xorg + nvidia
In-Reply-To: <20080725200923.GB14202@stranger.qboosh.pl>
References: <89b6ba3a0807250627l4ef0dc54m633513e796491f7f@mail.gmail.com>
	<89b6ba3a0807251257v1701ba21t38a755e45f4b3af5@mail.gmail.com>
	<20080725200923.GB14202@stranger.qboosh.pl>
Message-ID: <200807261544.51863.glen@delfi.ee>

On Friday 25 July 2008 23:09, Jakub Bogusz wrote:
> > but still the current solution breaks multiple kernels
> > (two kernel modules require two different versions of the same
> > package).
>
> At least release should be dropped from kernel module R.
> Anyway, I don't like hard kernel/userspace dependencies in any
> direction - maybe it should be Conflicts (<%{version}, >%{version},
> no release) or Suggests.

this also disables install of multiple kernel package versions.

and one can use /etc/rpm/sysinfo/Providename to satisfy missing kernel 
dependencies. (however current rpm.spec overwrites files with upgrade, we 
should %config(noreplace) them)

-- 
glen


From glen at delfi.ee  Sat Jul 26 14:45:54 2008
From: glen at delfi.ee (Elan =?iso-8859-15?q?Ruusam=E4e?=)
Date: Sat, 26 Jul 2008 15:45:54 +0300
Subject: SPECS: xorg-driver-video-nvidia.spec - let kernel require
	userspace, so the...
In-Reply-To: <200807252059.44168.kamil.listy@klecza.pl>
References: <SPECS_xorg_driver_video_nvidia.spec.1.163@pld-linux.org>
	<SPECS_xorg_driver_video_nvidia.spec.1.164@pld-linux.org>
	<200807252059.44168.kamil.listy@klecza.pl>
Message-ID: <200807261545.54470.glen@delfi.ee>

On Friday 25 July 2008 21:59, Kamil Dziedzic wrote:
> > Author: glen ? ? ? ? ? ? ? ? ? ? ? ? Date: Fri Jul 25 13:23:48 2008 GMT
> > Module: SPECS ? ? ? ? ? ? ? ? ? ? ? ? Tag: HEAD
> > @@ -264,8 +264,9 @@
> > ?cat << 'EOF'
> > ?NOTE: You must also install kernel module for this driver to work
> > ? ?kernel-video-nvidia-%{version}
> > - ?kernel-laptop-video-nvidia-%{version}
> > ? ?kernel-desktop-video-nvidia-%{version}
> > + ?kernel-laptop-video-nvidia-%{version}
> > + ?kernel-vanilla-video-nvidia-%{version}
> >
> > ?Depending on which kernel brand you use.
>
> Maybe instead note better will be Suggests? P: and S:
> kernel-module-video-nvidia?
>
> AFAIR suggests by default are not used by rpm? Right?

what do you mean by "not used" ?

-- 
glen


From glen at pld-linux.org  Sat Jul 26 14:50:48 2008
From: glen at pld-linux.org (Elan =?iso-8859-1?q?Ruusam=E4e?=)
Date: Sat, 26 Jul 2008 15:50:48 +0300
Subject: SOURCES: kde4-kdewebdev-findtidy.patch (NEW) - commit as binary
	file
In-Reply-To: <SOURCES_kde4_kdewebdev_findtidy.patch.1.7@pld-linux.org>
References: <SOURCES_kde4_kdewebdev_findtidy.patch.1.6@pld-linux.org>
	<SOURCES_kde4_kdewebdev_findtidy.patch.1.7@pld-linux.org>
Message-ID: <200807261550.48429.glen@pld-linux.org>

On Friday 25 July 2008 22:34, arekm wrote:
> +--- kdewebdev-4.1.0/klinkstatus/src/tidy/tidyx.h???????2008-01-05
> 00:56:02.000000000 +0100 ++++
> kdewebdev-4.1.0.new/klinkstatus/src/tidy/tidyx.h???2008-07-25
> 09:41:35.009138861 +0200 +@@ -48,8 +48,8 @@
> + ? Created 2002-07-11 by Charles Reitzel
> + */
> +
> +-#include <tidy/tidy.h>
> +-#include <tidy/buffio.h>
> ++#include <tidy.h>
> ++#include <buffio.h>

why not "fix" tidy package instead, i.e package to subdir the headers.

-- 
glen


From udvzsolt at gmail.com  Sat Jul 26 15:55:37 2008
From: udvzsolt at gmail.com (Zsolt Udvari)
Date: Sat, 26 Jul 2008 15:55:37 +0200
Subject: MPD startup script
Message-ID: <760ece280807260655h67b25c8dw5a483551d6824068@mail.gmail.com>

Hi all!

I see that there isn't mpd init-script.
So I've written it, I hope its good. And imho you'll include it to mpd package.

Zsolt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mpd
Type: application/octet-stream
Size: 866 bytes
Desc: not available
URL: </mailman/pipermail/pld-devel-en/attachments/20080726/a7dabf5f/attachment.obj>

From beorn at alpha.pl  Sat Jul 26 17:17:39 2008
From: beorn at alpha.pl (Daniel =?utf-8?B?TXLDs3o=?=)
Date: Sat, 26 Jul 2008 17:17:39 +0200
Subject: MPD startup script
In-Reply-To: <760ece280807260655h67b25c8dw5a483551d6824068@mail.gmail.com>
References: <760ece280807260655h67b25c8dw5a483551d6824068@mail.gmail.com>
Message-ID: <20080726151739.GA27946@alpha.pl>

On Sat, Jul 26, 2008 at 03:55:37PM +0200, Zsolt Udvari wrote:
> I see that there isn't mpd init-script.
> So I've written it, I hope its good. And imho you'll include it to mpd package.
It makes sense only in single-user system or when music library is
shared among all accounts. I think your script should be distributed
in a separate package (i.e. mpd-init), with separate mpd user.


Regards
Beorn

-- 
Daniel 'Beorn' Mr?z <beorn at alpha.pl>    http://127.0.0.1/beorn
[GIT d s:- a-@ C++++ UL++++$ P+ L++++ E--- W+ N+++ o? K- w---]
[O- M- V!  PS+ PE++ Y+ PGP++ t- 5  X R !tv b+ DI D++ G++ e h*]
[                          r++  y+                           ]


From kamil.listy at klecza.pl  Sat Jul 26 21:01:08 2008
From: kamil.listy at klecza.pl (Kamil Dziedzic)
Date: Sat, 26 Jul 2008 21:01:08 +0200
Subject: SPECS: xorg-driver-video-nvidia.spec - let kernel require
	userspace, so the...
In-Reply-To: <200807261545.54470.glen@delfi.ee>
References: <SPECS_xorg_driver_video_nvidia.spec.1.163@pld-linux.org>
	<200807252059.44168.kamil.listy@klecza.pl>
	<200807261545.54470.glen@delfi.ee>
Message-ID: <200807262101.12225.kamil.listy@klecza.pl>

Dnia sobota 26 lipiec 2008, Elan Ruusam?e napisa?:
> On Friday 25 July 2008 21:59, Kamil Dziedzic wrote:
> > > Author: glen ? ? ? ? ? ? ? ? ? ? ? ? Date: Fri Jul 25 13:23:48 2008 GMT
> > > Module: SPECS ? ? ? ? ? ? ? ? ? ? ? ? Tag: HEAD
> > > @@ -264,8 +264,9 @@
> > > ?cat << 'EOF'
> > > ?NOTE: You must also install kernel module for this driver to work
> > > ? ?kernel-video-nvidia-%{version}
> > > - ?kernel-laptop-video-nvidia-%{version}
> > > ? ?kernel-desktop-video-nvidia-%{version}
> > > + ?kernel-laptop-video-nvidia-%{version}
> > > + ?kernel-vanilla-video-nvidia-%{version}
> > >
> > > ?Depending on which kernel brand you use.
> >
> > Maybe instead note better will be Suggests? P: and S:
> > kernel-module-video-nvidia?
> >
> > AFAIR suggests by default are not used by rpm? Right?
>
> what do you mean by "not used" ?

They aren't treat by default as Requires by rpm so this doesn't brake rule 
not requiring kernel by userspace.

BTW. I didn't notice that there is similar thread already started when I was 
creating this so I think better will be to continue discussion in first one. 
Especially that qbosh already pointed Suggests;)

-- 
Regards, Kamil Dziedzic
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: </mailman/pipermail/pld-devel-en/attachments/20080726/198fbe8e/attachment.sig>

From kamil.listy at klecza.pl  Sat Jul 26 21:01:34 2008
From: kamil.listy at klecza.pl (Kamil Dziedzic)
Date: Sat, 26 Jul 2008 21:01:34 +0200
Subject: SPECS: mcs.spec - release 2
In-Reply-To: <SPECS_mcs.spec.1.22@pld-linux.org>
References: <SPECS_mcs.spec.1.21@pld-linux.org>
	<SPECS_mcs.spec.1.22@pld-linux.org>
Message-ID: <200807262101.34937.kamil.listy@klecza.pl>

Dnia sobota 26 lipiec 2008, arekm napisa?:
> Author: arekm                        Date: Sat Jul 26 16:03:37 2008 GMT
> Index: SPECS/mcs.spec
> diff -u SPECS/mcs.spec:1.21 SPECS/mcs.spec:1.22
> --- SPECS/mcs.spec:1.21	Sat Jul 26 16:37:25 2008
> +++ SPECS/mcs.spec	Sat Jul 26 18:03:32 2008
> @@ -3,7 +3,7 @@
>  Summary(pl.UTF-8):	mcs - prosta, abstrakcyjna biblioteka konfiguracji
>  Name:		mcs
>  Version:	0.7.1
> -Release:	1
> +Release:	2
>  License:	BSD
>  Group:		Development/Tools
>  Source0:	http://distfiles.atheme.org/lib%{name}-%{version}.tgz
> @@ -176,6 +176,9 @@
>  All persons listed below can be reached at <cvs_login>@pld-linux.org
>
>  $Log$
> +Revision 1.22  2008/07/26 16:03:32  arekm
> +- release 2
> +
>  Revision 1.21  2008/07/26 14:37:25  arvenil
>  - up to 0.7.1
>

Yes my fault but shouldn't fail build of libmowgli.spec when builder can't 
upgrade this package?

-- 
Regards, Kamil Dziedzic
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: </mailman/pipermail/pld-devel-en/attachments/20080726/23de8c22/attachment.sig>

From arekm at maven.pl  Sat Jul 26 20:14:53 2008
From: arekm at maven.pl (Arkadiusz Miskiewicz)
Date: Sat, 26 Jul 2008 20:14:53 +0200
Subject: SPECS: mcs.spec - release 2
In-Reply-To: <200807262101.34937.kamil.listy@klecza.pl>
References: <SPECS_mcs.spec.1.21@pld-linux.org>
	<SPECS_mcs.spec.1.22@pld-linux.org>
	<200807262101.34937.kamil.listy@klecza.pl>
Message-ID: <200807262014.53341.arekm@maven.pl>

On Saturday 26 July 2008, Kamil Dziedzic wrote:
> Dnia sobota 26 lipiec 2008, arekm napisa?:
> > Author: arekm                        Date: Sat Jul 26 16:03:37 2008 GMT
> > Index: SPECS/mcs.spec
> > diff -u SPECS/mcs.spec:1.21 SPECS/mcs.spec:1.22
> > --- SPECS/mcs.spec:1.21	Sat Jul 26 16:37:25 2008
> > +++ SPECS/mcs.spec	Sat Jul 26 18:03:32 2008
> > @@ -3,7 +3,7 @@
> >  Summary(pl.UTF-8):	mcs - prosta, abstrakcyjna biblioteka konfiguracji
> >  Name:		mcs
> >  Version:	0.7.1
> > -Release:	1
> > +Release:	2
> >  License:	BSD
> >  Group:		Development/Tools
> >  Source0:	http://distfiles.atheme.org/lib%{name}-%{version}.tgz
> > @@ -176,6 +176,9 @@
> >  All persons listed below can be reached at <cvs_login>@pld-linux.org
> >
> >  $Log$
> > +Revision 1.22  2008/07/26 16:03:32  arekm
> > +- release 2
> > +
> >  Revision 1.21  2008/07/26 14:37:25  arvenil
> >  - up to 0.7.1
>
> Yes my fault but shouldn't fail build of libmowgli.spec when builder can't
> upgrade this package?

It shouldn't since build itself was correct one.

Actually one thing could be improved. Automatic uninstallation of package and 
all deps when such thing happens.

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


From kamil.listy at klecza.pl  Sat Jul 26 23:31:54 2008
From: kamil.listy at klecza.pl (Kamil Dziedzic)
Date: Sat, 26 Jul 2008 23:31:54 +0200
Subject: SPECS: mcs.spec - release 2
In-Reply-To: <200807262014.53341.arekm@maven.pl>
References: <SPECS_mcs.spec.1.21@pld-linux.org>
	<200807262101.34937.kamil.listy@klecza.pl>
	<200807262014.53341.arekm@maven.pl>
Message-ID: <200807262331.59405.kamil.listy@klecza.pl>

Arkadiusz Miskiewicz wrote:
> Actually one thing could be improved. Automatic uninstallation of package
> and all deps when such thing happens.
+1 or at least any warning will be good.

-- 
Regards, Kamil Dziedzic
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: </mailman/pipermail/pld-devel-en/attachments/20080726/5203ef12/attachment.sig>

From arekm at maven.pl  Sat Jul 26 21:49:02 2008
From: arekm at maven.pl (Arkadiusz Miskiewicz)
Date: Sat, 26 Jul 2008 21:49:02 +0200
Subject: SPECS: mcs.spec - release 2
In-Reply-To: <200807262331.59405.kamil.listy@klecza.pl>
References: <SPECS_mcs.spec.1.21@pld-linux.org>
	<200807262014.53341.arekm@maven.pl>
	<200807262331.59405.kamil.listy@klecza.pl>
Message-ID: <200807262149.02585.arekm@maven.pl>

On Saturday 26 July 2008, Kamil Dziedzic wrote:
> Arkadiusz Miskiewicz wrote:
> > Actually one thing could be improved. Automatic uninstallation of package
> > and all deps when such thing happens.
>
> +1 or at least any warning will be good.

Warning was inside of build log.

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


From kamil.listy at klecza.pl  Sun Jul 27 00:04:09 2008
From: kamil.listy at klecza.pl (Kamil Dziedzic)
Date: Sun, 27 Jul 2008 00:04:09 +0200
Subject: SPECS: mcs.spec - release 2
In-Reply-To: <200807262149.02585.arekm@maven.pl>
References: <SPECS_mcs.spec.1.21@pld-linux.org>
	<200807262331.59405.kamil.listy@klecza.pl>
	<200807262149.02585.arekm@maven.pl>
Message-ID: <200807270004.10088.kamil.listy@klecza.pl>

Arkadiusz Miskiewicz:
> Warning was inside of build log.

I know but I read it after you bump revision... so you want to tell me I 
should read each buildlog for each arch even if build is marked as OK?;)

By "any warning" I mean that maybe besides "OK" and "FAIL" there should 
be "WARNING" state. But of course removing package and all it dependencies 
automatically is probably better idea.

-- 
Regards, Kamil Dziedzic
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: </mailman/pipermail/pld-devel-en/attachments/20080727/781fe162/attachment.sig>

From arekm at maven.pl  Sat Jul 26 22:12:46 2008
From: arekm at maven.pl (Arkadiusz Miskiewicz)
Date: Sat, 26 Jul 2008 22:12:46 +0200
Subject: SPECS: mcs.spec - release 2
In-Reply-To: <200807270004.10088.kamil.listy@klecza.pl>
References: <SPECS_mcs.spec.1.21@pld-linux.org>
	<200807262149.02585.arekm@maven.pl>
	<200807270004.10088.kamil.listy@klecza.pl>
Message-ID: <200807262212.47021.arekm@maven.pl>

On Sunday 27 July 2008, Kamil Dziedzic wrote:
> Arkadiusz Miskiewicz:
> > Warning was inside of build log.
>
> I know but I read it after you bump revision... so you want to tell me I
> should read each buildlog for each arch even if build is marked as OK?;)

Look at buildlog email subject: upgrade failed OK: libmowgli.spec

>
> By "any warning" I mean that maybe besides "OK" and "FAIL" there should
> be "WARNING" state. But of course removing package and all it dependencies
> automatically is probably better idea.

Maybe that can be done. Not sure.

Check CVS/pld-builder.new/ for builder code and send patches :-)

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


From glen at pld-linux.org  Mon Jul 28 01:50:48 2008
From: glen at pld-linux.org (Elan =?utf-8?q?Ruusam=C3=A4e?=)
Date: Mon, 28 Jul 2008 02:50:48 +0300
Subject: SPECS: kvm.spec - Up to 72 - Removed kernel module build (kvm.ko
	is now par...
In-Reply-To: <SPECS_kvm.spec.1.42@pld-linux.org>
References: <SPECS_kvm.spec.1.41@pld-linux.org>
	<SPECS_kvm.spec.1.42@pld-linux.org>
Message-ID: <200807280250.48905.glen@pld-linux.org>

On Sunday 27 July 2008 22:20, beorn wrote:
>  %define	date	%(echo `LC_ALL="C" date +"%a %b %d %Y"`)
>  %changelog
> @@ -185,6 +115,11 @@
>  All persons listed below can be reached at <cvs_login>@pld-linux.org
>
>  $Log$
> +Revision 1.42  2008/07/27 19:20:01  beorn
> +- Up to 72
> +- Removed kernel module build (kvm.ko is now part of the kernel)
> +- Needs checking on various CPUs, especially on PPC (there were some fixes
> upstream)! +

so what is it?

firstly i recall updates were moved to DEVEL due they were not usable, 
secondly i recall kvm was disabled from kernel.spec due we have kvm.spec

-- 
glen


From udvzsolt at gmail.com  Mon Jul 28 13:37:35 2008
From: udvzsolt at gmail.com (Zsolt Udvari)
Date: Mon, 28 Jul 2008 13:37:35 +0200
Subject: SPEC: fet
Message-ID: <760ece280807280437k76d9560ci96ca716e072bc4e6@mail.gmail.com>

Hi!

fet is a free timetabling program. I hope that this spec-file is
(almost) perfect ;)

Zsolt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fet.spec
Type: application/octet-stream
Size: 1602 bytes
Desc: not available
URL: </mailman/pipermail/pld-devel-en/attachments/20080728/90ecbb40/attachment.obj>

From adamg at biomerieux.pl  Mon Jul 28 13:43:24 2008
From: adamg at biomerieux.pl (Adam =?utf-8?B?R2/FgsSZYmlvd3NraQ==?=)
Date: Mon, 28 Jul 2008 13:43:24 +0200
Subject: SPEC: fet
In-Reply-To: <760ece280807280437k76d9560ci96ca716e072bc4e6@mail.gmail.com>
References: <760ece280807280437k76d9560ci96ca716e072bc4e6@mail.gmail.com>
Message-ID: <20080728114324.GB22687@mysza.eu.org>

On Mon, Jul 28, 2008 at 01:37:35PM +0200, Zsolt Udvari wrote:
> Hi!
> 
> fet is a free timetabling program. I hope that this spec-file is
> (almost) perfect ;)

Unfortunately, it's not -- it does not fully comply with PLD style.

There's a handy little tool, called adapter  (cvs::SPECS/adapter and
cvs::SPECS/adapter.awk), that does some basic checks and proposes
changes in an unified diff format. 

Have a look at it and see what it thinks about fet.spec

-- 
 http://www.mysza.eu.org/ | Everybody needs someone sure, someone true,
   PLD Linux developer    | Everybody needs some solid rock, I know I do.


From udvzsolt at gmail.com  Mon Jul 28 13:55:04 2008
From: udvzsolt at gmail.com (Zsolt Udvari)
Date: Mon, 28 Jul 2008 13:55:04 +0200
Subject: SPEC: fet
In-Reply-To: <20080728114324.GB22687@mysza.eu.org>
References: <760ece280807280437k76d9560ci96ca716e072bc4e6@mail.gmail.com>
	<20080728114324.GB22687@mysza.eu.org>
Message-ID: <760ece280807280455s1fe35faao7c2f0beda117697d@mail.gmail.com>

> Have a look at it and see what it thinks about fet.spec
Thanks, here is a perfect version :)

# adapter fet.spec
The SPEC is perfect ;)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fet.spec
Type: application/octet-stream
Size: 1638 bytes
Desc: not available
URL: </mailman/pipermail/pld-devel-en/attachments/20080728/a8e071fa/attachment.obj>

From z at grabina.waw.pl  Mon Jul 28 14:29:18 2008
From: z at grabina.waw.pl (=?utf-8?q?Pawe=C5=82_Zuzelski?=)
Date: Mon, 28 Jul 2008 14:29:18 +0200
Subject: SPEC: fet
In-Reply-To: <760ece280807280455s1fe35faao7c2f0beda117697d@mail.gmail.com>
References: <760ece280807280437k76d9560ci96ca716e072bc4e6@mail.gmail.com>
	<20080728114324.GB22687@mysza.eu.org>
	<760ece280807280455s1fe35faao7c2f0beda117697d@mail.gmail.com>
Message-ID: <200807281429.18207.z@grabina.waw.pl>

On Monday 28 of July 2008 13:55:04 Zsolt Udvari wrote:
> > Have a look at it and see what it thinks about fet.spec
>
> Thanks, here is a perfect version :)
>
> # adapter fet.spec
> The SPEC is perfect ;)

It looks better now, but still it is not perfect. There are some hints:

 * use install instead of cp -r in %install section
 * do not install COPYING - it contains well known GPLv2 licence.
 * add summary and description in your national language (hungarian?) (-;

-- 
Regards,
Pawel Zuzelski


From udvzsolt at gmail.com  Mon Jul 28 15:30:31 2008
From: udvzsolt at gmail.com (Zsolt Udvari)
Date: Mon, 28 Jul 2008 15:30:31 +0200
Subject: SPEC: fet
In-Reply-To: <200807281429.18207.z@grabina.waw.pl>
References: <760ece280807280437k76d9560ci96ca716e072bc4e6@mail.gmail.com>
	<20080728114324.GB22687@mysza.eu.org>
	<760ece280807280455s1fe35faao7c2f0beda117697d@mail.gmail.com>
	<200807281429.18207.z@grabina.waw.pl>
Message-ID: <760ece280807280630q19f52357p7275bc4efabdafa5@mail.gmail.com>

Here is the next version :)

Zsolt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fet.spec
Type: application/octet-stream
Size: 2028 bytes
Desc: not available
URL: </mailman/pipermail/pld-devel-en/attachments/20080728/9ab282f3/attachment.obj>

From z at grabina.waw.pl  Mon Jul 28 18:29:13 2008
From: z at grabina.waw.pl (=?utf-8?q?Pawe=C5=82_Zuzelski?=)
Date: Mon, 28 Jul 2008 16:29:13 +0000
Subject: SPEC: fet
In-Reply-To: <760ece280807280630q19f52357p7275bc4efabdafa5@mail.gmail.com>
References: <760ece280807280437k76d9560ci96ca716e072bc4e6@mail.gmail.com>
	<200807281429.18207.z@grabina.waw.pl>
	<760ece280807280630q19f52357p7275bc4efabdafa5@mail.gmail.com>
Message-ID: <200807281629.14076.z@grabina.waw.pl>

On Monday 28 July 2008 13:30:31 Zsolt Udvari wrote:
> Here is the next version :)

It does not build for me (th/i686). Here is builder output: 
http://user.touk.pl/pzz/fet.log

-- 
Pawel Zuzelski


From udvzsolt at gmail.com  Mon Jul 28 19:35:19 2008
From: udvzsolt at gmail.com (Zsolt Udvari)
Date: Mon, 28 Jul 2008 19:35:19 +0200
Subject: SPEC: fet
In-Reply-To: <200807281629.14076.z@grabina.waw.pl>
References: <760ece280807280437k76d9560ci96ca716e072bc4e6@mail.gmail.com>
	<200807281429.18207.z@grabina.waw.pl>
	<760ece280807280630q19f52357p7275bc4efabdafa5@mail.gmail.com>
	<200807281629.14076.z@grabina.waw.pl>
Message-ID: <760ece280807281035s62c53616sc9c06aadd4b81fa1@mail.gmail.com>

> It does not build for me (th/i686). Here is builder output:
> http://user.touk.pl/pzz/fet.log
Hm, I hate the devel-packages. So some devel-dependencies are missed
:( This is my fault :(
I hope that this version works.

Is there any solution to find what devel packages are needed? IMHO
maybe can grep the source tree what headers are included and sort
them, but I can't send it to poldek.
What I'm thinking:
grep "\#include *<" $(find ../BUILD/fet-5.6.0/ -iname "*.h" -o -iname
"*.cpp" ) | awk -F ":" {'print $2'} | awk {'print $2'} | sort -u | sed
"s@<\(.*\)>@search -f /usr/include/\1@"
This script create the list which contains all system-wide headers
what the program want to include.
And it'd be good to know that what packages provides these files. OK,
I can pipe to poldek but when the included files are very much it
takes a very long time.
Is there any way to do this faster?

Zsolt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fet.spec
Type: application/octet-stream
Size: 2113 bytes
Desc: not available
URL: </mailman/pipermail/pld-devel-en/attachments/20080728/4f13c536/attachment.obj>

From z at grabina.waw.pl  Mon Jul 28 20:22:51 2008
From: z at grabina.waw.pl (=?utf-8?q?Pawe=C5=82_Zuzelski?=)
Date: Mon, 28 Jul 2008 18:22:51 +0000
Subject: SPEC: fet
In-Reply-To: <760ece280807281035s62c53616sc9c06aadd4b81fa1@mail.gmail.com>
References: <760ece280807280437k76d9560ci96ca716e072bc4e6@mail.gmail.com>
	<200807281629.14076.z@grabina.waw.pl>
	<760ece280807281035s62c53616sc9c06aadd4b81fa1@mail.gmail.com>
Message-ID: <200807281822.51771.z@grabina.waw.pl>

On Monday 28 July 2008 17:35:19 Zsolt Udvari wrote:
> > It does not build for me (th/i686). Here is builder output:
> > http://user.touk.pl/pzz/fet.log
>
> Hm, I hate the devel-packages. So some devel-dependencies are missed

No, the devel dependencies are ok. Something is wrong with qmake-qt4 and 
src/interface/Makefile.

INCPATH in Makefile generated at my system does not points to c++ include 
dir...

-- 
Pawe? Zuzelski



From sls at poczta.wp.pl  Mon Jul 28 20:29:06 2008
From: sls at poczta.wp.pl (Szymon Siwek)
Date: Mon, 28 Jul 2008 20:29:06 +0200
Subject: SPEC: fet
In-Reply-To: <200807281429.18207.z@grabina.waw.pl>
References: <760ece280807280437k76d9560ci96ca716e072bc4e6@mail.gmail.com>
	<20080728114324.GB22687@mysza.eu.org>
	<760ece280807280455s1fe35faao7c2f0beda117697d@mail.gmail.com>
	<200807281429.18207.z@grabina.waw.pl>
Message-ID: <20080728182906.GA31777@cion.siwster.com>

On Mon, Jul 28, 2008 at 02:29:18PM +0200, Pawe? Zuzelski wrote:
> On Monday 28 of July 2008 13:55:04 Zsolt Udvari wrote:
> > > Have a look at it and see what it thinks about fet.spec
> >
> > Thanks, here is a perfect version :)
> >
> > # adapter fet.spec
> > The SPEC is perfect ;)
> 
> It looks better now, but still it is not perfect. There are some hints:
> 
[...]
>  * add summary and description in your national language (hungarian?) (-;
> 
... if you want be awarded Order Of Labour Glory. If you add summaries and
descriptions in hungarian for all specs you'll be awarded Order Of The Red
Banner Of Labour.
Seriously - it's good to have descriptions in all languages but only
english is required - for example glen doesn't care about estonian
translations.

-- 
Szymon Siwek


From sls at poczta.wp.pl  Mon Jul 28 20:33:46 2008
From: sls at poczta.wp.pl (Szymon Siwek)
Date: Mon, 28 Jul 2008 20:33:46 +0200
Subject: SPEC: fet
In-Reply-To: <760ece280807281035s62c53616sc9c06aadd4b81fa1@mail.gmail.com>
References: <760ece280807280437k76d9560ci96ca716e072bc4e6@mail.gmail.com>
	<200807281429.18207.z@grabina.waw.pl>
	<760ece280807280630q19f52357p7275bc4efabdafa5@mail.gmail.com>
	<200807281629.14076.z@grabina.waw.pl>
	<760ece280807281035s62c53616sc9c06aadd4b81fa1@mail.gmail.com>
Message-ID: <20080728183346.GA8316@cion.siwster.com>

On Mon, Jul 28, 2008 at 07:35:19PM +0200, Zsolt Udvari wrote:
> > It does not build for me (th/i686). Here is builder output:
> > http://user.touk.pl/pzz/fet.log
> Hm, I hate the devel-packages. So some devel-dependencies are missed
> :( This is my fault :(
> I hope that this version works.
> 
Works for me.

> Is there any solution to find what devel packages are needed? 
There is no simple solution, I believe.

> IMHO
> maybe can grep the source tree what headers are included and sort
> them, but I can't send it to poldek.
> What I'm thinking:
> grep "\#include *<" $(find ../BUILD/fet-5.6.0/ -iname "*.h" -o -iname
> "*.cpp" ) | awk -F ":" {'print $2'} | awk {'print $2'} | sort -u | sed
> "s@<\(.*\)>@search -f /usr/include/\1@"
> This script create the list which contains all system-wide headers
> what the program want to include.

... and what about conditional includes?

> And it'd be good to know that what packages provides these files. OK,
> I can pipe to poldek but when the included files are very much it
> takes a very long time.
> Is there any way to do this faster?
> 
> Zsolt

-- 
Szymon Siwek


From ankry at green.mif.pg.gda.pl  Mon Jul 28 21:57:47 2008
From: ankry at green.mif.pg.gda.pl (Andrzej Krzysztofowicz)
Date: Mon, 28 Jul 2008 21:57:47 +0200 (CEST)
Subject: SPEC: fet
In-Reply-To: <760ece280807281035s62c53616sc9c06aadd4b81fa1@mail.gmail.com>
	from "Zsolt Udvari" at Jul 28, 2008 07:35:19 PM
Message-ID: <200807281957.m6SJvlG9017971@green.mif.pg.gda.pl>

Zsolt Udvari wrote:
> What I'm thinking:
> grep "\#include *<" $(find ../BUILD/fet-5.6.0/ -iname "*.h" -o -iname
> "*.cpp" ) | awk -F ":" {'print $2'} | awk {'print $2'} | sort -u | sed
> "s@<\(.*\)>@search -f /usr/include/\1@"
> This script create the list which contains all system-wide headers
> what the program want to include.
> And it'd be good to know that what packages provides these files. OK,
> I can pipe to poldek but when the included files are very much it
> takes a very long time.
> Is there any way to do this faster?

rpm -qf ?

-- 
=======================================================================
  Andrzej M. Krzysztofowicz                  ankry at mif.pg.gda.pl
  phone (48)(58) 347 19 36
Faculty of Applied Phys. & Math.,   Gdansk University of Technology


From gotar at polanet.pl  Mon Jul 28 22:02:25 2008
From: gotar at polanet.pl (Tomasz Pala)
Date: Mon, 28 Jul 2008 22:02:25 +0200
Subject: SPEC: fet
In-Reply-To: <760ece280807281035s62c53616sc9c06aadd4b81fa1@mail.gmail.com>
References: <760ece280807280437k76d9560ci96ca716e072bc4e6@mail.gmail.com>
	<200807281429.18207.z@grabina.waw.pl>
	<760ece280807280630q19f52357p7275bc4efabdafa5@mail.gmail.com>
	<200807281629.14076.z@grabina.waw.pl>
	<760ece280807281035s62c53616sc9c06aadd4b81fa1@mail.gmail.com>
Message-ID: <20080728200225.GA12088@pepin.polanet.pl>

On Mon, Jul 28, 2008 at 19:35:19 +0200, Zsolt Udvari wrote:

> Is there any solution to find what devel packages are needed? IMHO

rpm -e *devel

;)

BTW

#v+

%install
rm -rf $RPM_BUILD_ROOT
install -d $RPM_BUILD_ROOT{%{_bindir},%{_mandir}/man1,%{_datadir}/%{name}/{sample_inputs,translations}}

install fet $RPM_BUILD_ROOT%{_bindir}
install doc/fet.1 $RPM_BUILD_ROOT%{_mandir}/man1
install sample_inputs/* $RPM_BUILD_ROOT%{_datadir}/%{name}/sample_inputs
install translations/* $RPM_BUILD_ROOT%{_datadir}/%{name}/translations

%clean
rm -rf $RPM_BUILD_ROOT

#v-

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


From sls at poczta.wp.pl  Mon Jul 28 22:14:13 2008
From: sls at poczta.wp.pl (Szymon Siwek)
Date: Mon, 28 Jul 2008 22:14:13 +0200
Subject: SPEC: fet
In-Reply-To: <20080728183346.GA8316@cion.siwster.com>
References: <760ece280807280437k76d9560ci96ca716e072bc4e6@mail.gmail.com>
	<200807281429.18207.z@grabina.waw.pl>
	<760ece280807280630q19f52357p7275bc4efabdafa5@mail.gmail.com>
	<200807281629.14076.z@grabina.waw.pl>
	<760ece280807281035s62c53616sc9c06aadd4b81fa1@mail.gmail.com>
	<20080728183346.GA8316@cion.siwster.com>
Message-ID: <20080728201413.GA19608@cion.siwster.com>

On Mon, Jul 28, 2008 at 08:33:46PM +0200, Szymon Siwek wrote:
> On Mon, Jul 28, 2008 at 07:35:19PM +0200, Zsolt Udvari wrote:
> > > It does not build for me (th/i686). Here is builder output:
> > > http://user.touk.pl/pzz/fet.log
> > Hm, I hate the devel-packages. So some devel-dependencies are missed
> > :( This is my fault :(
> > I hope that this version works.
> > 
> Works for me.
> 
Actually, rpmbuild -bc works for me. But rpmbuild -bi fails on installing
some sample_inputs dirs.

I read spec so I've got some hints:
- remove trailing slashes from lines like this
  "install -d $RPM_BUILD_ROOT%{_bindir}/"
- translation files should be packaged with %lang()
- I guess sample_inputs should be packaged as %doc (and not installed into
  _datadir/name)
- libstdc++-devel is required by QtCore-devel (BR)
  so "BuildRequires: libstdc++-devel" should be removed

-- 
Szymon Siwek


From z at grabina.waw.pl  Mon Jul 28 22:18:44 2008
From: z at grabina.waw.pl (=?utf-8?q?Pawe=C5=82_Zuzelski?=)
Date: Mon, 28 Jul 2008 20:18:44 +0000
Subject: SPEC: fet
In-Reply-To: <20080728183346.GA8316@cion.siwster.com>
References: <760ece280807280437k76d9560ci96ca716e072bc4e6@mail.gmail.com>
	<760ece280807281035s62c53616sc9c06aadd4b81fa1@mail.gmail.com>
	<20080728183346.GA8316@cion.siwster.com>
Message-ID: <200807282018.44795.z@grabina.waw.pl>

On Monday 28 July 2008 18:33:46 Szymon Siwek wrote:
> On Mon, Jul 28, 2008 at 07:35:19PM +0200, Zsolt Udvari wrote:
> > > It does not build for me (th/i686). Here is builder output:
> > > http://user.touk.pl/pzz/fet.log
> >
> > Hm, I hate the devel-packages. So some devel-dependencies are missed
> >
> > :( This is my fault :(
> >
> > I hope that this version works.
>
> Works for me.

OK, it works for me too - after upgrade of gcc.

It works on gcc-c++-4.2.4-1 and newer.
It does not work on gcc-c++-4.2.3-1.

So there sould be BR gcc-c++ >= 4.2.4-1

-- 
Pawe? Zuzelski


From blues at pld-linux.org  Tue Jul 29 11:04:08 2008
From: blues at pld-linux.org (Pawel Golaszewski)
Date: Tue, 29 Jul 2008 11:04:08 +0200 (CEST)
Subject: SPECS: kvm.spec - don't require external qemu, doesn't make sense.
In-Reply-To: <200807252344.52247.kamil.listy@klecza.pl>
References: <SPECS_kvm.spec.1.40@pld-linux.org>
	<SPECS_kvm.spec.1.41@pld-linux.org>
	<200807090156.07887.glen@pld-linux.org>
	<200807252344.52247.kamil.listy@klecza.pl>
Message-ID: <alpine.LNX.1.10.0807291101570.22634@fgnss.gnfx.tqn.cy>

On Fri, 25 Jul 2008, Kamil Dziedzic wrote:
> > >  $Log$
> > > +Revision 1.41  2008/07/08 21:41:32  blues
> > > +- don't require external qemu, doesn't make sense.
> > why so? the /usr/share part is common, binary from kvm is just 
> > patched.
> No response = reverting.

There was response.



Have you tried to build qemu? do it...
Maybe some parts should be in some "common" subpackage with 
conflict/obsoletes itself but... I don't want to play it...

-- 
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 udvzsolt at gmail.com  Tue Jul 29 12:37:37 2008
From: udvzsolt at gmail.com (Zsolt Udvari)
Date: Tue, 29 Jul 2008 12:37:37 +0200
Subject: SPEC: fet
In-Reply-To: <20080728201413.GA19608@cion.siwster.com>
References: <760ece280807280437k76d9560ci96ca716e072bc4e6@mail.gmail.com>
	<200807281429.18207.z@grabina.waw.pl>
	<760ece280807280630q19f52357p7275bc4efabdafa5@mail.gmail.com>
	<200807281629.14076.z@grabina.waw.pl>
	<760ece280807281035s62c53616sc9c06aadd4b81fa1@mail.gmail.com>
	<20080728183346.GA8316@cion.siwster.com>
	<20080728201413.GA19608@cion.siwster.com>
Message-ID: <760ece280807290337i58539f30x3d3379437e610f17@mail.gmail.com>

> - remove trailing slashes from lines like this
>  "install -d $RPM_BUILD_ROOT%{_bindir}/"
OK.

> - translation files should be packaged with %lang()
And will they placed to a good place?

> - I guess sample_inputs should be packaged as %doc (and not installed into
>  _datadir/name)
And they will not packed with gzip?

> - libstdc++-devel is required by QtCore-devel (BR)
>  so "BuildRequires: libstdc++-devel" should be removed
OK.

Zsolt


From udvzsolt at gmail.com  Tue Jul 29 20:10:28 2008
From: udvzsolt at gmail.com (Zsolt Udvari)
Date: Tue, 29 Jul 2008 20:10:28 +0200
Subject: SPEC awesome update
Message-ID: <760ece280807291110o475869bcx2b6c4fc2f8d66f4e@mail.gmail.com>

Changes:
* change version to 2.3.3
* change md5sum
-------------- next part --------------
A non-text attachment was scrubbed...
Name: awesome.spec
Type: application/octet-stream
Size: 2444 bytes
Desc: not available
URL: </mailman/pipermail/pld-devel-en/attachments/20080729/763ed5db/attachment.obj>

From z at grabina.waw.pl  Tue Jul 29 21:53:06 2008
From: z at grabina.waw.pl (=?utf-8?q?Pawe=C5=82_Zuzelski?=)
Date: Tue, 29 Jul 2008 19:53:06 +0000
Subject: SPEC awesome update
In-Reply-To: <760ece280807291110o475869bcx2b6c4fc2f8d66f4e@mail.gmail.com>
References: <760ece280807291110o475869bcx2b6c4fc2f8d66f4e@mail.gmail.com>
Message-ID: <200807291953.06690.z@grabina.waw.pl>

On Tuesday 29 July 2008 18:10:28 Zsolt Udvari wrote:
> Changes:
> * change version to 2.3.3
> * change md5sum

One more awesome user? Awesome is awesome (-:

Commited, thanks. What about Hungarian desc and summary?

BTW: If you post diff -u instead whole spec it will be easier to verify your 
changes.

-- 
Pawe? Zuzelski


From patrys at pld-linux.org  Wed Jul 30 00:16:38 2008
From: patrys at pld-linux.org (Patryk Zawadzki)
Date: Wed, 30 Jul 2008 00:16:38 +0200
Subject: SPEC awesome update
In-Reply-To: <200807291953.06690.z@grabina.waw.pl>
References: <760ece280807291110o475869bcx2b6c4fc2f8d66f4e@mail.gmail.com>
	<200807291953.06690.z@grabina.waw.pl>
Message-ID: <89b6ba3a0807291516l69e16ef1l24cf38fad0a9dcfe@mail.gmail.com>

On Tue, Jul 29, 2008 at 9:53 PM, Pawe? Zuzelski <z at grabina.waw.pl> wrote:
> On Tuesday 29 July 2008 18:10:28 Zsolt Udvari wrote:
>> Changes:
>> * change version to 2.3.3
>> * change md5sum
> One more awesome user? Awesome is awesome (-:

+1 in case anyone proposes rw access (I won't be the one as I'm
currently busy with GNOME so I can't really check someone else's
commits)

;]

-- 
Patryk Zawadzki

From qboosh at pld-linux.org  Wed Jul 30 00:28:22 2008
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Wed, 30 Jul 2008 00:28:22 +0200
Subject: SPECS: bmpx.spec - changed name of mozilla-firefox-plugin-bmpx
	package to i...
In-Reply-To: <SPECS_bmpx.spec.1.91@pld-linux.org>
References: <SPECS_bmpx.spec.1.90@pld-linux.org>
	<SPECS_bmpx.spec.1.91@pld-linux.org>
Message-ID: <20080729222822.GA20132@stranger.qboosh.pl>

On Fri, Jul 25, 2008 at 11:16:10PM +0200, megabajt wrote:
> Author: megabajt                     Date: Fri Jul 25 21:16:10 2008 GMT
> Module: SPECS                         Tag: HEAD
> ---- Log message:
> - changed name of mozilla-firefox-plugin-bmpx package to iceweasel-extension-bmpx

> -%package -n mozilla-firefox-plugin-bmpx
> -Summary:	BMPx plugin for Mozilla Firefox
> -Summary(pl.UTF-8):	Wtyczka BMPx dla Mozilli Firefox
> +%package -n iceweasel-extension-bmpx
> +Summary:	Iceweasel extension - BMPx
> +Summary(pl.UTF-8):	Rozszerzenie dla przegl?darki Iceweasel - BMPx
>  Group:		X11/Applications
>  Requires:	%{name} = %{version}-%{release}
> -Requires:	mozilla-firefox >= 2.0.0.1-2
> -
> -%description -n mozilla-firefox-plugin-bmpx
> -This plugin registers the lastfm:// protocol to BMPx.
> -
> -%description -n mozilla-firefox-plugin-bmpx -l pl.UTF-8
> -Ta wtyczka rejestruje protok?? lastfm:// do BMPx.
> +Requires:	iceweasel

What is this? Why not browser-plugins?


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


From megabajt at pld-linux.org  Wed Jul 30 01:15:36 2008
From: megabajt at pld-linux.org (Marcin Banasiak)
Date: Wed, 30 Jul 2008 01:15:36 +0200
Subject: SPECS: bmpx.spec - changed name of mozilla-firefox-plugin-bmpx
	package to i...
In-Reply-To: <20080729222822.GA20132@stranger.qboosh.pl>
References: <SPECS_bmpx.spec.1.90@pld-linux.org>
	<SPECS_bmpx.spec.1.91@pld-linux.org>
	<20080729222822.GA20132@stranger.qboosh.pl>
Message-ID: <6e5c47670807291615h75432ef6o24238d0c60d3460f@mail.gmail.com>

Jakub Bogusz wrote:
[...]
> What is this? Why not browser-plugins?

mozilla-firefox has been replaced by iceweasel in Th, that is why I
changed name of this package.

I know that browser-plugins would be the best solution, but I'm not
sure whether it supports this kind of extensions.

-- 
Marcin Banasiak


From glen at pld-linux.org  Wed Jul 30 08:59:27 2008
From: glen at pld-linux.org (Elan =?iso-8859-1?q?Ruusam=E4e?=)
Date: Wed, 30 Jul 2008 09:59:27 +0300
Subject: Fwd: Returned mail: see transcript for details
Message-ID: <200807300959.27360.glen@pld-linux.org>

err? why wiki marks email came from @pld-linux.org while it's not neccessary 
valid user?

-- 
glen
-------------- next part --------------
An embedded message was scrubbed...
From: Mail Delivery Subsystem <MAILER-DAEMON at mail.eunet.ee>
Subject: Returned mail: see transcript for details
Date: Wed, 30 Jul 2008 02:14:48 +0300
Size: 4264
URL: </mailman/pipermail/pld-devel-en/attachments/20080730/aa84802f/attachment.eml>

From zbyniu at geocarbon.pl  Wed Jul 30 09:42:42 2008
From: zbyniu at geocarbon.pl (Zbyniu Krzystolik)
Date: Wed, 30 Jul 2008 09:42:42 +0200
Subject: Fwd: Returned mail: see transcript for details
In-Reply-To: <200807300959.27360.glen@pld-linux.org>
References: <200807300959.27360.glen@pld-linux.org>
Message-ID: <20080730074242.GR7731@geocarbon.pl>

Mniej wiecej Wed, Jul 30, 2008 at 09:59:27AM +0300, zainteresowany Elan Ruusam?e rzekl:
> err? why wiki marks email came from @pld-linux.org while it's not neccessary 
> valid user?
>    ----- The following addresses had permanent fatal errors -----
> <grizz at pld-linux.org>
>     (reason: 550 5.1.1 <grizz at pld-linux.org>: Recipient address rejected: User unknown)

[zbyniu at altus rpm]$ grep grizz CVSROOT/users
[zbyniu at altus rpm]$

No such developer.

Zbyniu
-- 
%% Absolutely nothing we trust %%


From udvzsolt at gmail.com  Wed Jul 30 10:07:57 2008
From: udvzsolt at gmail.com (Zsolt Udvari)
Date: Wed, 30 Jul 2008 10:07:57 +0200
Subject: SPEC awesome update
In-Reply-To: <200807291953.06690.z@grabina.waw.pl>
References: <760ece280807291110o475869bcx2b6c4fc2f8d66f4e@mail.gmail.com>
	<200807291953.06690.z@grabina.waw.pl>
Message-ID: <760ece280807300107k72585bd6n24bdae11d999e2cd@mail.gmail.com>

> One more awesome user? Awesome is awesome (-:
Yes :) I thought too that I'm the only awesome-user in pld-users...
And maybe if you don't know about awesome-status, see
http://udvzsolt.extra.hu/download.php?list.18
And maybe you want to try newsbeuter news reader (I've send the spec
file last week).

> Commited, thanks. What about Hungarian desc and summary?
Do you want this really? OK ;)

> BTW: If you post diff -u instead whole spec it will be easier to verify your
> changes.
So, here is the diff.

Zsolt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: awesome.diff
Type: application/octet-stream
Size: 664 bytes
Desc: not available
URL: </mailman/pipermail/pld-devel-en/attachments/20080730/9ee2460a/attachment.obj>

From glen at pld-linux.org  Wed Jul 30 10:35:58 2008
From: glen at pld-linux.org (Elan =?iso-8859-1?q?Ruusam=E4e?=)
Date: Wed, 30 Jul 2008 11:35:58 +0300
Subject: Fwd: Returned mail: see transcript for details
In-Reply-To: <20080730074242.GR7731@geocarbon.pl>
References: <200807300959.27360.glen@pld-linux.org>
	<20080730074242.GR7731@geocarbon.pl>
Message-ID: <200807301135.58925.glen@pld-linux.org>

On Wednesday 30 July 2008 10:42:42 Zbyniu Krzystolik wrote:
> Mniej wiecej Wed, Jul 30, 2008 at 09:59:27AM +0300, zainteresowany Elan 
Ruusam?e rzekl:
> > err? why wiki marks email came from @pld-linux.org while it's not
> > neccessary valid user?
> >    ----- The following addresses had permanent fatal errors -----
> > <grizz at pld-linux.org>
> >     (reason: 550 5.1.1 <grizz at pld-linux.org>: Recipient address rejected:
> > User unknown)
>
> [zbyniu at altus rpm]$ grep grizz CVSROOT/users
> [zbyniu at altus rpm]$
>
> No such developer.

did i ask that? read again original question please :)

> Zbyniu

-- 
glen


From glen at pld-linux.org  Thu Jul 31 08:54:25 2008
From: glen at pld-linux.org (Elan =?iso-8859-1?q?Ruusam=E4e?=)
Date: Thu, 31 Jul 2008 09:54:25 +0300
Subject: SPECS: cmake.spec - even more :/
In-Reply-To: <SPECS_cmake.spec.1.27@pld-linux.org>
References: <SPECS_cmake.spec.1.26@pld-linux.org>
	<SPECS_cmake.spec.1.27@pld-linux.org>
Message-ID: <200807310954.28025.glen@pld-linux.org>

On Thursday 31 July 2008 07:45, qboosh wrote:
> +# - rpmldflags/rpmcppflags are not passed through %%cmake macro at all
> +# ? (is there any standard way???)

there isn't (this has gone over devel-en list already at least twice).

however i've tried to use in few places our standard, ie the ones we use in 
autoconf:

# override __cmake to add -j4 in your ~/.rpmmacros for parallel make
%__cmake    /usr/bin/cmake
%cmake { \
CC="%{__cc}" \
CXX="%{__cxx}" \
CFLAGS="%{rpmcflags}" \
CXXFLAGS="%{rpmcxxflags}" \
%{__cmake} \
}

another place i recall, where these compiler options are not accepted is 
apache modules via apxs, they use cc and flags from apache compile time.

-- 
glen


From glen at pld-linux.org  Thu Jul 31 08:56:39 2008
From: glen at pld-linux.org (Elan =?iso-8859-1?q?Ruusam=E4e?=)
Date: Thu, 31 Jul 2008 09:56:39 +0300
Subject: SOURCES: rpm.macros - pass LDFLAGS for cmake - removed bogus
	comment
In-Reply-To: <SOURCES_rpm.macros.1.471@pld-linux.org>
References: <SOURCES_rpm.macros.1.470@pld-linux.org>
	<SOURCES_rpm.macros.1.471@pld-linux.org>
Message-ID: <200807310956.41550.glen@pld-linux.org>

On Thursday 31 July 2008 08:48, qboosh wrote:
> - removed bogus comment
..
> -# override __cmake to add -j4 in your ~/.rpmmacros for parallel make
> ?%__cmake???????/usr/bin/cmake

cmake doesn't have -jN ?

-- 
glen


From arekm at maven.pl  Thu Jul 31 09:07:04 2008
From: arekm at maven.pl (Arkadiusz Miskiewicz)
Date: Thu, 31 Jul 2008 09:07:04 +0200
Subject: SPECS: cmake.spec - even more :/
In-Reply-To: <200807310954.28025.glen@pld-linux.org>
References: <SPECS_cmake.spec.1.26@pld-linux.org>
	<SPECS_cmake.spec.1.27@pld-linux.org>
	<200807310954.28025.glen@pld-linux.org>
Message-ID: <200807310907.04399.arekm@maven.pl>

On Thursday 31 July 2008, Elan Ruusam?e wrote:
> On Thursday 31 July 2008 07:45, qboosh wrote:
> > +# - rpmldflags/rpmcppflags are not passed through %%cmake macro at all
> > +# ? (is there any standard way???)
>
> there isn't (this has gone over devel-en list already at least twice).
>
> however i've tried to use in few places our standard, ie the ones we use in
> autoconf:
>
> # override __cmake to add -j4 in your ~/.rpmmacros for parallel make
> %__cmake    /usr/bin/cmake
> %cmake { \
> CC="%{__cc}" \
> CXX="%{__cxx}" \
> CFLAGS="%{rpmcflags}" \
> CXXFLAGS="%{rpmcxxflags}" \
> %{__cmake} \
> }

There is CPPFLAGS (%rpmcppflags), too (in Th).

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


From glen at delfi.ee  Thu Jul 31 13:01:45 2008
From: glen at delfi.ee (Elan =?iso-8859-1?q?Ruusam=E4e?=)
Date: Thu, 31 Jul 2008 14:01:45 +0300
Subject: SPECS: firephp.spec (NEW) - new (actually i have no idea how to
	package moz...
In-Reply-To: <SPECS_firephp.spec.1.1@pld-linux.org>
References: <SPECS_firephp.spec.NONE@pld-linux.org>
	<SPECS_firephp.spec.1.1@pld-linux.org>
Message-ID: <200807311401.45999.glen@delfi.ee>

On Thursday 31 July 2008 13:03:33 glen wrote:
> +# TODO
> +# - make it generic for gecko based browsers (browser-plugins should first
> support this)
> +# ? call it one of: (RFC welcome) 
> +# ? - browser-extension-gecko-firephp
> +# ? - gecko-addon-firephp
> +# ? - gecko-extension-firephp
> +# ? - mozilla-extension-firephp
> +# ? - mozilla-addon-firephp
> +Summary:???????Firefox Extension for FirePHP
> +Name:??????????firephp

i'd like to hear your opinion on the package namespace, so further packages 
could follow it.

-- 
glen


From tomasz.wittner at gmail.com  Thu Jul 31 15:06:55 2008
From: tomasz.wittner at gmail.com (Tomasz Wittner)
Date: Thu, 31 Jul 2008 15:06:55 +0200
Subject: SPECS: cmake.spec - even more :/
In-Reply-To: <200807310954.28025.glen@pld-linux.org>
References: <SPECS_cmake.spec.1.26@pld-linux.org>
	<SPECS_cmake.spec.1.27@pld-linux.org>
	<200807310954.28025.glen@pld-linux.org>
Message-ID: <200807311506.55164.tomasz.wittner@gmail.com>

On Thursday 31 of July 2008, 08:54, Elan Ruusam?e wrote:
> On Thursday 31 July 2008 07:45, qboosh wrote:
> > +# - rpmldflags/rpmcppflags are not passed through %%cmake macro at all
> > +# ? (is there any standard way???)
>
> there isn't (this has gone over devel-en list already at least twice).
>
> however i've tried to use in few places our standard, ie the ones we use in
> autoconf:
>
> # override __cmake to add -j4 in your ~/.rpmmacros for parallel make
> %__cmake    /usr/bin/cmake
> %cmake { \
> CC="%{__cc}" \
> CXX="%{__cxx}" \
> CFLAGS="%{rpmcflags}" \
> CXXFLAGS="%{rpmcxxflags}" \
> %{__cmake} \
> }
>
> another place i recall, where these compiler options are not accepted is
> apache modules via apxs, they use cc and flags from apache compile time.

The same story with ruby packages - most of them use ruby script which takes 
values of CC, CXX, C(XX)FLAGS from Config module 
(file /usr/lib/ruby/1.8/*-linux/rbconfig.rb). IMO there is no way other than 
patching these setup scripts one by one to accept CC, CXX, C(XX)FLAGS env. 
var. or taking flags via commandline switchs - IMO such patching doesn't pay, 
there is only one practical inconvenience which is raleted to passing CC/CXX 
values when ccache is used without symlinking compilers commands to ccache.

-- 
Tomasz Wittner


From tomasz.wittner at gmail.com  Thu Jul 31 15:07:24 2008
From: tomasz.wittner at gmail.com (Tomasz Wittner)
Date: Thu, 31 Jul 2008 15:07:24 +0200
Subject: SOURCES: rpm.macros - pass LDFLAGS for cmake - removed bogus
	comment
In-Reply-To: <200807310956.41550.glen@pld-linux.org>
References: <SOURCES_rpm.macros.1.470@pld-linux.org>
	<SOURCES_rpm.macros.1.471@pld-linux.org>
	<200807310956.41550.glen@pld-linux.org>
Message-ID: <200807311507.24697.tomasz.wittner@gmail.com>

On Thursday 31 of July 2008, 08:56, Elan Ruusam?e wrote:
> On Thursday 31 July 2008 08:48, qboosh wrote:
> > - removed bogus comment
>
> ..
>
> > -# override __cmake to add -j4 in your ~/.rpmmacros for parallel make
> > ?%__cmake???????/usr/bin/cmake
>
> cmake doesn't have -jN ?

Yes, it doesn't. Run (or read manpage) cmake command
$ cmake
cmake version 2.4-patch 8
Usage
[...]
and find -j option (there isn't).
-- 
Tomasz Wittner


From qboosh at pld-linux.org  Thu Jul 31 17:28:11 2008
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Thu, 31 Jul 2008 17:28:11 +0200
Subject: SOURCES: rpm.macros - pass LDFLAGS for cmake - removed bogus
	comment
In-Reply-To: <200807310956.41550.glen@pld-linux.org>
References: <SOURCES_rpm.macros.1.470@pld-linux.org>
	<SOURCES_rpm.macros.1.471@pld-linux.org>
	<200807310956.41550.glen@pld-linux.org>
Message-ID: <20080731152811.GA14078@stranger.qboosh.pl>

On Thu, Jul 31, 2008 at 09:56:39AM +0300, Elan Ruusam?e wrote:
> On Thursday 31 July 2008 08:48, qboosh wrote:
> > - removed bogus comment
> ..
> > -# override __cmake to add -j4 in your ~/.rpmmacros for parallel make
> > ?%__cmake???????/usr/bin/cmake
> 
> cmake doesn't have -jN ?

No. make does.


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


From qboosh at pld-linux.org  Thu Jul 31 17:35:39 2008
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Thu, 31 Jul 2008 17:35:39 +0200
Subject: SPECS: cmake.spec - even more :/
In-Reply-To: <200807310954.28025.glen@pld-linux.org>
References: <SPECS_cmake.spec.1.26@pld-linux.org>
	<SPECS_cmake.spec.1.27@pld-linux.org>
	<200807310954.28025.glen@pld-linux.org>
Message-ID: <20080731153539.GB14078@stranger.qboosh.pl>

On Thu, Jul 31, 2008 at 09:54:25AM +0300, Elan Ruusam?e wrote:
> On Thursday 31 July 2008 07:45, qboosh wrote:
> > +# - rpmldflags/rpmcppflags are not passed through %%cmake macro at all
> > +# ? (is there any standard way???)
> 
> there isn't (this has gone over devel-en list already at least twice).

Well, as I rechecked, at least cmake 2.6.0 respects LDFLAGS.
But it's all - no CPPFLAGS.

And use of any of predefined CMAKE_BUILD_TYPEs overrides
CFLAGS/CXXFLAGS (-Os/-O2/-O3 is added _after_ flags taken from
environment).

And there is no standard way to pass individual install directories, the
only one commonly used seems to be CMAKE_INSTALL_PREFIX.

I hate replacing autotools by something more problematic which isn't
even less complicated.


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


From qboosh at pld-linux.org  Thu Jul 31 17:57:49 2008
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Thu, 31 Jul 2008 17:57:49 +0200
Subject: SPECS: firephp.spec (NEW) - new (actually i have no idea how
	to package moz...
In-Reply-To: <200807311401.45999.glen@delfi.ee>
References: <SPECS_firephp.spec.NONE@pld-linux.org>
	<SPECS_firephp.spec.1.1@pld-linux.org>
	<200807311401.45999.glen@delfi.ee>
Message-ID: <20080731155749.GC14078@stranger.qboosh.pl>

On Thu, Jul 31, 2008 at 02:01:45PM +0300, Elan Ruusam?e wrote:
> On Thursday 31 July 2008 13:03:33 glen wrote:
> > +# TODO
> > +# - make it generic for gecko based browsers (browser-plugins should first
> > support this)
> > +# ? call it one of: (RFC welcome) 
> > +# ? - browser-extension-gecko-firephp
> > +# ? - gecko-addon-firephp
> > +# ? - gecko-extension-firephp
> > +# ? - mozilla-extension-firephp
> > +# ? - mozilla-addon-firephp
> > +Summary:???????Firefox Extension for FirePHP
> > +Name:??????????firephp
> 
> i'd like to hear your opinion on the package namespace, so further packages 
> could follow it.

Not mozilla-* (it's restricted name).
gecko-* or browser-gecko-*.
Or maybe browser-xul-extension-* (I'm not sure if these extensions are
more related to gecko or xul?)


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


From qboosh at pld-linux.org  Thu Jul 31 18:03:02 2008
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Thu, 31 Jul 2008 18:03:02 +0200
Subject: SPECS: cmake.spec - even more :/
In-Reply-To: <20080731153539.GB14078@stranger.qboosh.pl>
References: <SPECS_cmake.spec.1.26@pld-linux.org>
	<SPECS_cmake.spec.1.27@pld-linux.org>
	<200807310954.28025.glen@pld-linux.org>
	<20080731153539.GB14078@stranger.qboosh.pl>
Message-ID: <20080731160302.GD14078@stranger.qboosh.pl>

On Thu, Jul 31, 2008 at 05:35:39PM +0200, Jakub Bogusz wrote:
> On Thu, Jul 31, 2008 at 09:54:25AM +0300, Elan Ruusam?e wrote:
> > On Thursday 31 July 2008 07:45, qboosh wrote:
> > > +# - rpmldflags/rpmcppflags are not passed through %%cmake macro at all
> > > +# ? (is there any standard way???)
> > 
> > there isn't (this has gone over devel-en list already at least twice).
> 
> Well, as I rechecked, at least cmake 2.6.0 respects LDFLAGS.
> But it's all - no CPPFLAGS.
> 
> And use of any of predefined CMAKE_BUILD_TYPEs overrides
> CFLAGS/CXXFLAGS (-Os/-O2/-O3 is added _after_ flags taken from
> environment).
> 
> And there is no standard way to pass individual install directories, the
> only one commonly used seems to be CMAKE_INSTALL_PREFIX.

And one more, reminded by PLD-doc/BuildRequires.txt:

# NOTE: check *.so* perms, cmake usually sets 644 which prevents rpm from generating deps


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


From zbyniu at geocarbon.pl  Thu Jul  3 23:14:37 2008
From: zbyniu at geocarbon.pl (Zbyniu Krzystolik)
Date: Thu, 03 Jul 2008 21:14:37 -0000
Subject: SPECS (LINUX_2_6): kernel.spec - use underscore in kernel
	release for KABI ...
In-Reply-To: <200807031446.53900.glen@delfi.ee>
References: <SPECS_kernel.spec.1.441.2.1933@pld-linux.org>
	<SPECS_kernel.spec.1.441.2.1934@pld-linux.org>
	<20080703101246.GD9126@geocarbon.pl>
	<200807031446.53900.glen@delfi.ee>
Message-ID: <20080703115635.GE9126@geocarbon.pl>

Mniej wiecej Thu, Jul 03, 2008 at 02:46:53PM +0300, zainteresowany Elan Ruusam?e rzekl:
> On Thursday 03 July 2008 13:12, Zbyniu Krzystolik wrote:
> > Mniej wiecej Thu, Jul 03, 2008 at 11:17:20AM +0200, zainteresowany glen 
> rzekl:
> > > Author: glen                         Date: Thu Jul  3 09:17:20 2008 GMT
> > > Module: SPECS                         Tag: LINUX_2_6
> > > ---- Log message:
> > > - use underscore in kernel release for KABI to be a lit less misleading
> > >
> > > -%define		kernel_release
> > > %{version}%{?_alt_kernel:%{_alt_kernel}}-%{_localversion}
> > > +%define		kernel_release %{version}%{?_alt_kernel:%{_alt_kernel}}_%{KABI}
> >
> > What for? You are changing package name that exist since always and it
> > is "less misleading"?
> package name???
> 
> the change is there as %{kabi} != %{release} most of the time, 

Why not? new kernel vsersiona are in every week so kabi should be set to
1 every week.

> and you've used to that %{release} is last part in uname -r after dash.

ok, and let it be dash not underscore.

Zbyniu
-- 
%% Absolutely nothing we trust %%
_______________________________________________
pld-devel-pl mailing list
pld-devel-pl at lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl