From qboosh at pld-linux.org  Sat Apr  2 20:11:18 2011
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Sat, 2 Apr 2011 20:11:18 +0200
Subject: python3.2+ compiled files
Message-ID: <20110402181118.GA22787@stranger.qboosh.pl>

It seems that since python 3.2 upstream changed the default way
of creating compiled files: instead of *.pyc/*.pyo in the same
directory that .py file exists, the compiled files are created
in __pycache__ subdirectory.
According to some googled information, the "old method" (files created
in the same directory by compileall) still works in the same way.
In case of the "new method", compiled files are searched in __pycache__
subdirectory only if source file exists.

I'm not sure if the new method affects only (c)python 3.2 installation,
or all modules installed using distutils or so.

So we have to decide how to package python distribution (and possibly
all python3 modules, if distutils use __pycache__ too) - there are
two solutions:

- package all modules in source form together with __pycache__
  subdirectories

- stick to "old way" - manually py_comp/py_ocomp all python files,
  package *.py[co] without using __pycache__ subdirectories


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


From arekm at maven.pl  Sat Apr  2 20:22:25 2011
From: arekm at maven.pl (Arkadiusz Miskiewicz)
Date: Sat, 2 Apr 2011 20:22:25 +0200
Subject: python3.2+ compiled files
In-Reply-To: <20110402181118.GA22787@stranger.qboosh.pl>
References: <20110402181118.GA22787@stranger.qboosh.pl>
Message-ID: <201104022022.25649.arekm@maven.pl>

On Saturday 02 of April 2011, Jakub Bogusz wrote:

> So we have to decide how to package python distribution (and possibly
> all python3 modules, if distutils use __pycache__ too) - there are
> two solutions:
> 
> - package all modules in source form together with __pycache__
>   subdirectories

I would opt for this solution. We had many problems previously due to removing 
py files and py files are very usefull when debugging or working with python 
libraries.

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


From patrys at pld-linux.org  Sun Apr  3 03:29:53 2011
From: patrys at pld-linux.org (Patryk Zawadzki)
Date: Sun, 3 Apr 2011 03:29:53 +0200
Subject: python3.2+ compiled files
In-Reply-To: <201104022022.25649.arekm@maven.pl>
References: <20110402181118.GA22787@stranger.qboosh.pl>
	<201104022022.25649.arekm@maven.pl>
Message-ID: <AANLkTi=pF=5wUywx8JRN647im064pubxq8u8M0D7mmSu@mail.gmail.com>

On Sat, Apr 2, 2011 at 8:22 PM, Arkadiusz Miskiewicz <arekm at maven.pl> wrote:
> On Saturday 02 of April 2011, Jakub Bogusz wrote:
>> So we have to decide how to package python distribution (and possibly
>> all python3 modules, if distutils use __pycache__ too) - there are
>> two solutions:
>>
>> - package all modules in source form together with __pycache__
>> ? subdirectories
> I would opt for this solution. We had many problems previously due to removing
> py files and py files are very usefull when debugging or working with python
> libraries.

+1, lots of software depends on being able to find .py files (plugin
discovery) and sources are often the only source of (up to date)
documentation. I currently keep a lot of source packages around in my
home dir because files coming from PLD packages are only readable to
python itself.

-- 
Patryk Zawadzki
I solve problems.


From wolf.pld at gmail.com  Sun Apr  3 14:21:19 2011
From: wolf.pld at gmail.com (Bartosz Taudul)
Date: Sun, 3 Apr 2011 14:21:19 +0200
Subject: python3.2+ compiled files
In-Reply-To: <AANLkTi=pF=5wUywx8JRN647im064pubxq8u8M0D7mmSu@mail.gmail.com>
References: <20110402181118.GA22787@stranger.qboosh.pl>
	<201104022022.25649.arekm@maven.pl>
	<AANLkTi=pF=5wUywx8JRN647im064pubxq8u8M0D7mmSu@mail.gmail.com>
Message-ID: <BANLkTim7aB=zi9A6TSn7REvpZkR1c-jjgw@mail.gmail.com>

On Sun, Apr 3, 2011 at 3:29 AM, Patryk Zawadzki <patrys at pld-linux.org> wrote:
>> I would opt for this solution. We had many problems previously due to removing
>> py files and py files are very usefull when debugging or working with python
>> libraries.
Again with this stupid argument? Will we also pack C/C++ sources in
packages, because they are useful for debugging?

> +1, lots of software depends on being able to find .py files (plugin
> discovery)
So lots of software is broken by design. What else is new?

> and sources are often the only source of (up to date)
> documentation.
So the source code is the documentation. What else is new? Are you
simply trolling, or just are too ignorant to be aware that's also what
happens with all other programming languages?

> I currently keep a lot of source packages around in my
> home dir because files coming from PLD packages are only readable to
> python itself.
Your point beign? You want to have source code, you have to get it by
yourself, and not rely on the distribution to bend to your nonsensical
needs. What's next? Kernel people requiring full kernel sources in
main package, because they do some work with them? Shadzik wanting to
package full KDE source code in our packages, so that he can apply
patches with less effort? Oh wait, at least that's not going to happen
anymore.

> Patryk Zawadzki
> I solve problems.

wolf
I ROTFL at PZ.


From patrys at pld-linux.org  Sun Apr  3 14:38:49 2011
From: patrys at pld-linux.org (Patryk Zawadzki)
Date: Sun, 3 Apr 2011 14:38:49 +0200
Subject: python3.2+ compiled files
In-Reply-To: <BANLkTim7aB=zi9A6TSn7REvpZkR1c-jjgw@mail.gmail.com>
References: <20110402181118.GA22787@stranger.qboosh.pl>
	<201104022022.25649.arekm@maven.pl>
	<AANLkTi=pF=5wUywx8JRN647im064pubxq8u8M0D7mmSu@mail.gmail.com>
	<BANLkTim7aB=zi9A6TSn7REvpZkR1c-jjgw@mail.gmail.com>
Message-ID: <BANLkTimEVS5_PeEwgp9fpoKcMOhu1e2Fcw@mail.gmail.com>

On Sun, Apr 3, 2011 at 2:21 PM, Bartosz Taudul <wolf.pld at gmail.com> wrote:
> On Sun, Apr 3, 2011 at 3:29 AM, Patryk Zawadzki <patrys at pld-linux.org> wrote:
>>> I would opt for this solution. We had many problems previously due to removing
>>> py files and py files are very usefull when debugging or working with python
>>> libraries.
> Again with this stupid argument? Will we also pack C/C++ sources in
> packages, because they are useful for debugging?

C/C++ works in an entirely different way. Do you propose we
minify/obfuscate .php files before distributing them?

>> +1, lots of software depends on being able to find .py files (plugin
>> discovery)
> So lots of software is broken by design. What else is new?

So you volunteer to fix the whole world in a way compatible with what
everyone else uses. And maintain the patches.

>> and sources are often the only source of (up to date)
>> documentation.
> So the source code is the documentation. What else is new? Are you
> simply trolling, or just are too ignorant to be aware that's also what
> happens with all other programming languages?

Except in Python you can execute/import .py files just fine. If the
program is not closed source, .pyc/.pyo/__pycache__ are just an
optimization detail. We could very well create them in %post.

<poor flame removed>

-- 
Patryk Zawadzki
I solve problems.


From wolf.pld at gmail.com  Sun Apr  3 14:45:49 2011
From: wolf.pld at gmail.com (Bartosz Taudul)
Date: Sun, 3 Apr 2011 14:45:49 +0200
Subject: python3.2+ compiled files
In-Reply-To: <BANLkTimEVS5_PeEwgp9fpoKcMOhu1e2Fcw@mail.gmail.com>
References: <20110402181118.GA22787@stranger.qboosh.pl>
	<201104022022.25649.arekm@maven.pl>
	<AANLkTi=pF=5wUywx8JRN647im064pubxq8u8M0D7mmSu@mail.gmail.com>
	<BANLkTim7aB=zi9A6TSn7REvpZkR1c-jjgw@mail.gmail.com>
	<BANLkTimEVS5_PeEwgp9fpoKcMOhu1e2Fcw@mail.gmail.com>
Message-ID: <BANLkTi=+oB9ryr4Qyj+xmQF4DMR7bzMWOQ@mail.gmail.com>

On Sun, Apr 3, 2011 at 2:38 PM, Patryk Zawadzki <patrys at pld-linux.org> wrote:
<lame trolling removed>

Sorry, your post came in empty.

wolf


From n3npq at mac.com  Sun Apr  3 14:51:30 2011
From: n3npq at mac.com (Jeff Johnson)
Date: Sun, 03 Apr 2011 08:51:30 -0400
Subject: python3.2+ compiled files
In-Reply-To: <BANLkTimEVS5_PeEwgp9fpoKcMOhu1e2Fcw@mail.gmail.com>
References: <20110402181118.GA22787@stranger.qboosh.pl>
	<201104022022.25649.arekm@maven.pl>
	<AANLkTi=pF=5wUywx8JRN647im064pubxq8u8M0D7mmSu@mail.gmail.com>
	<BANLkTim7aB=zi9A6TSn7REvpZkR1c-jjgw@mail.gmail.com>
	<BANLkTimEVS5_PeEwgp9fpoKcMOhu1e2Fcw@mail.gmail.com>
Message-ID: <9F4F25B4-67AA-4183-9527-8A5753689412@mac.com>


On Apr 3, 2011, at 8:38 AM, Patryk Zawadzki wrote:
> 
>>> and sources are often the only source of (up to date)
>>> documentation.
>> So the source code is the documentation. What else is new? Are you
>> simply trolling, or just are too ignorant to be aware that's also what
>> happens with all other programming languages?
> 
> Except in Python you can execute/import .py files just fine. If the
> program is not closed source, .pyc/.pyo/__pycache__ are just an
> optimization detail. We could very well create them in %post.
> 

Not %post please ;-)

But I'd generally agree that the compilation might
need to be done on the install, not during the build, given
just the few hints of how python 3.2 is changing.

Another approach would be to not bother with static *.py* content
packaged in *.rpm at all, but rather let python establish its own
format/implementation for install/upgrade/erase of python code.

73 de Jeff



From mmazur at kernel.pl  Sun Apr  3 14:55:17 2011
From: mmazur at kernel.pl (Mariusz Mazur)
Date: Sun, 3 Apr 2011 14:55:17 +0200
Subject: python3.2+ compiled files
In-Reply-To: <20110402181118.GA22787@stranger.qboosh.pl>
References: <20110402181118.GA22787@stranger.qboosh.pl>
Message-ID: <201104031455.17414.mmazur@kernel.pl>

On Saturday 02 of April 2011, Jakub Bogusz wrote:

> - package all modules in source form together with __pycache__
>   subdirectories

+1

--mmazur


From ankry at green.mif.pg.gda.pl  Sun Apr  3 15:00:40 2011
From: ankry at green.mif.pg.gda.pl (ankry at green.mif.pg.gda.pl)
Date: Sun, 3 Apr 2011 15:00:40 +0200 (CEST)
Subject: python3.2+ compiled files
In-Reply-To: <9F4F25B4-67AA-4183-9527-8A5753689412@mac.com>
Message-ID: <201104031300.p33D0eiY004923@green.mif.pg.gda.pl>

Jeff Johnson wrote:
> Another approach would be to not bother with static *.py* content
> packaged in *.rpm at all, but rather let python establish its own
> format/implementation for install/upgrade/erase of python code.

This approach would break the main PLD rule: that all binaries present in
the system are registered in the rpm database.

-- 
=======================================================================
  Andrzej M. Krzysztofowicz                  ankry at mif.pg.gda.pl


From jajcus at jajcus.net  Sun Apr  3 15:04:19 2011
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Sun, 3 Apr 2011 15:04:19 +0200
Subject: python3.2+ compiled files
In-Reply-To: <BANLkTimEVS5_PeEwgp9fpoKcMOhu1e2Fcw@mail.gmail.com>
References: <20110402181118.GA22787@stranger.qboosh.pl>
	<201104022022.25649.arekm@maven.pl>
	<AANLkTi=pF=5wUywx8JRN647im064pubxq8u8M0D7mmSu@mail.gmail.com>
	<BANLkTim7aB=zi9A6TSn7REvpZkR1c-jjgw@mail.gmail.com>
	<BANLkTimEVS5_PeEwgp9fpoKcMOhu1e2Fcw@mail.gmail.com>
Message-ID: <20110403130419.GA4399@lolek.nigdzie>

On Sun, Apr 03, 2011 at 02:38:49PM +0200, Patryk Zawadzki wrote:
> Except in Python you can execute/import .py files just fine. If the
> program is not closed source, .pyc/.pyo/__pycache__ are just an
> optimization detail. We could very well create them in %post.

That is a very bad idea. Bad things will happen if the package is
removed and *.py[o] stays (the module will still be visible to Python).
Best way to make sure 'compiled' files are gone when the package is gone
is to include them in the package.

Just a reminder: not including 'compiled' files in the package at all
would be even worse: those would be generated (and stay forever) when
root runs the code and would not when other user does. 

Greets,
        Jacek


From n3npq at mac.com  Sun Apr  3 15:07:41 2011
From: n3npq at mac.com (Jeff Johnson)
Date: Sun, 03 Apr 2011 09:07:41 -0400
Subject: python3.2+ compiled files
In-Reply-To: <201104031300.p33D0eiY004923@green.mif.pg.gda.pl>
References: <201104031300.p33D0eiY004923@green.mif.pg.gda.pl>
Message-ID: <E5F3D83C-DAB4-4D23-9E24-6E6C7F8250AE@mac.com>


On Apr 3, 2011, at 9:00 AM, ankry at green.mif.pg.gda.pl wrote:

> Jeff Johnson wrote:
>> Another approach would be to not bother with static *.py* content
>> packaged in *.rpm at all, but rather let python establish its own
>> format/implementation for install/upgrade/erase of python code.
> 
> This approach would break the main PLD rule: that all binaries present in
> the system are registered in the rpm database.
> 

rules == rules

So teach python to do a registration. That's already being
done with pubkeys and rpm --import: create a header, call rpmdbAdd().

73 de Jeff


From patrys at pld-linux.org  Sun Apr  3 15:15:06 2011
From: patrys at pld-linux.org (Patryk Zawadzki)
Date: Sun, 3 Apr 2011 15:15:06 +0200
Subject: python3.2+ compiled files
In-Reply-To: <20110403130419.GA4399@lolek.nigdzie>
References: <20110402181118.GA22787@stranger.qboosh.pl>
	<201104022022.25649.arekm@maven.pl>
	<AANLkTi=pF=5wUywx8JRN647im064pubxq8u8M0D7mmSu@mail.gmail.com>
	<BANLkTim7aB=zi9A6TSn7REvpZkR1c-jjgw@mail.gmail.com>
	<BANLkTimEVS5_PeEwgp9fpoKcMOhu1e2Fcw@mail.gmail.com>
	<20110403130419.GA4399@lolek.nigdzie>
Message-ID: <BANLkTi=DMmohQf6g8ASHxCzgBJ3RihYGpA@mail.gmail.com>

On Sun, Apr 3, 2011 at 3:04 PM, Jacek Konieczny <jajcus at jajcus.net> wrote:
> On Sun, Apr 03, 2011 at 02:38:49PM +0200, Patryk Zawadzki wrote:
>> Except in Python you can execute/import .py files just fine. If the
>> program is not closed source, .pyc/.pyo/__pycache__ are just an
>> optimization detail. We could very well create them in %post.
> That is a very bad idea. Bad things will happen if the package is
> removed and *.py[o] stays (the module will still be visible to Python).
> Best way to make sure 'compiled' files are gone when the package is gone
> is to include them in the package.

We have %ghost and we can remove such files on uninstallation. My
point is that .py[co] is how even more of an optimization detail than
it was before. Can any other implementation of python handle
__pycache__? What if two packages install a file to somedir/? Which
gets to own __pycache__? Can python itself remove obsolete caches when
politely asked? Can it keep the __pycache__ tree in a separate prefix
instead of along the files?

-- 
Patryk Zawadzki
I solve problems.


From n3npq at mac.com  Sun Apr  3 15:27:34 2011
From: n3npq at mac.com (Jeff Johnson)
Date: Sun, 03 Apr 2011 09:27:34 -0400
Subject: python3.2+ compiled files
In-Reply-To: <BANLkTi=DMmohQf6g8ASHxCzgBJ3RihYGpA@mail.gmail.com>
References: <20110402181118.GA22787@stranger.qboosh.pl>
	<201104022022.25649.arekm@maven.pl>
	<AANLkTi=pF=5wUywx8JRN647im064pubxq8u8M0D7mmSu@mail.gmail.com>
	<BANLkTim7aB=zi9A6TSn7REvpZkR1c-jjgw@mail.gmail.com>
	<BANLkTimEVS5_PeEwgp9fpoKcMOhu1e2Fcw@mail.gmail.com>
	<20110403130419.GA4399@lolek.nigdzie>
	<BANLkTi=DMmohQf6g8ASHxCzgBJ3RihYGpA@mail.gmail.com>
Message-ID: <268F066B-3BF4-4FC6-B83C-1CB8979F6E2B@mac.com>


On Apr 3, 2011, at 9:15 AM, Patryk Zawadzki wrote:

> On Sun, Apr 3, 2011 at 3:04 PM, Jacek Konieczny <jajcus at jajcus.net> wrote:
>> On Sun, Apr 03, 2011 at 02:38:49PM +0200, Patryk Zawadzki wrote:
>>> Except in Python you can execute/import .py files just fine. If the
>>> program is not closed source, .pyc/.pyo/__pycache__ are just an
>>> optimization detail. We could very well create them in %post.
>> That is a very bad idea. Bad things will happen if the package is
>> removed and *.py[o] stays (the module will still be visible to Python).
>> Best way to make sure 'compiled' files are gone when the package is gone
>> is to include them in the package.
> 
> We have %ghost and we can remove such files on uninstallation. My
> point is that .py[co] is how even more of an optimization detail than
> it was before. Can any other implementation of python handle
> __pycache__? What if two packages install a file to somedir/? Which
> gets to own __pycache__? Can python itself remove obsolete caches when
> politely asked? Can it keep the __pycache__ tree in a separate prefix
> instead of along the files?
> 

And not %ghost please: st->st_mode typing and other "useful" info is
lacking for paths marked %ghost.

(aside)
There's no reason whatsoever that %ghost-like cannot be extended
to include other info that is necessary.

I see a problem with /usr/bin/__pycache__/* and the rest of
the python litter on a file system. While __pycache__ subdirs "works" in python's
module trees, there will be a litter of __pycache__ subdirs on other
paths.

But can't a shadow tree (perhaps /var/cache/python/usr/bin/__pycache__/*?) be done?

Another alternative might be a python modules whose sole purpose
is/was to create a shadow tree within /usr/lib/python/X.Y/... for
use by python executables installed in /usr/bin etc ...

hth

73 de Jeff



From patrys at pld-linux.org  Sun Apr  3 22:01:32 2011
From: patrys at pld-linux.org (Patryk Zawadzki)
Date: Sun, 3 Apr 2011 22:01:32 +0200
Subject: python3.2+ compiled files
In-Reply-To: <268F066B-3BF4-4FC6-B83C-1CB8979F6E2B@mac.com>
References: <20110402181118.GA22787@stranger.qboosh.pl>
	<201104022022.25649.arekm@maven.pl>
	<AANLkTi=pF=5wUywx8JRN647im064pubxq8u8M0D7mmSu@mail.gmail.com>
	<BANLkTim7aB=zi9A6TSn7REvpZkR1c-jjgw@mail.gmail.com>
	<BANLkTimEVS5_PeEwgp9fpoKcMOhu1e2Fcw@mail.gmail.com>
	<20110403130419.GA4399@lolek.nigdzie>
	<BANLkTi=DMmohQf6g8ASHxCzgBJ3RihYGpA@mail.gmail.com>
	<268F066B-3BF4-4FC6-B83C-1CB8979F6E2B@mac.com>
Message-ID: <BANLkTinc-_8KMFFJgQ5w9Lbm7-_91H0R0g@mail.gmail.com>

On Sun, Apr 3, 2011 at 3:27 PM, Jeff Johnson <n3npq at mac.com> wrote:
> I see a problem with /usr/bin/__pycache__/* and the rest of
> the python litter on a file system. While __pycache__ subdirs "works" in python's
> module trees, there will be a litter of __pycache__ subdirs on other
> paths.
>
> But can't a shadow tree (perhaps /var/cache/python/usr/bin/__pycache__/*?) be done?

That's exactly what I mean, ideally we'd have cached pre-compiled
files built somewhere in /var/cache for root and ~/.local/cache for
local files.

-- 
Patryk Zawadzki
I solve problems.


From n3npq at mac.com  Sun Apr  3 22:11:14 2011
From: n3npq at mac.com (Jeff Johnson)
Date: Sun, 03 Apr 2011 16:11:14 -0400
Subject: python3.2+ compiled files
In-Reply-To: <BANLkTinc-_8KMFFJgQ5w9Lbm7-_91H0R0g@mail.gmail.com>
References: <20110402181118.GA22787@stranger.qboosh.pl>
	<201104022022.25649.arekm@maven.pl>
	<AANLkTi=pF=5wUywx8JRN647im064pubxq8u8M0D7mmSu@mail.gmail.com>
	<BANLkTim7aB=zi9A6TSn7REvpZkR1c-jjgw@mail.gmail.com>
	<BANLkTimEVS5_PeEwgp9fpoKcMOhu1e2Fcw@mail.gmail.com>
	<20110403130419.GA4399@lolek.nigdzie>
	<BANLkTi=DMmohQf6g8ASHxCzgBJ3RihYGpA@mail.gmail.com>
	<268F066B-3BF4-4FC6-B83C-1CB8979F6E2B@mac.com>
	<BANLkTinc-_8KMFFJgQ5w9Lbm7-_91H0R0g@mail.gmail.com>
Message-ID: <8A1A79E1-0041-43AB-BF6D-D24B916B3356@mac.com>


On Apr 3, 2011, at 4:01 PM, Patryk Zawadzki wrote:

> On Sun, Apr 3, 2011 at 3:27 PM, Jeff Johnson <n3npq at mac.com> wrote:
>> I see a problem with /usr/bin/__pycache__/* and the rest of
>> the python litter on a file system. While __pycache__ subdirs "works" in python's
>> module trees, there will be a litter of __pycache__ subdirs on other
>> paths.
>> 
>> But can't a shadow tree (perhaps /var/cache/python/usr/bin/__pycache__/*?) be done?
> 
> That's exactly what I mean, ideally we'd have cached pre-compiled
> files built somewhere in /var/cache for root and ~/.local/cache for
> local files.
> 

Please note that there's _NEVER_ been any real world
reason to package up pure side-effects for any of
	/sbin/ldconfig symlinks
	sockets   (why bother with a path that is always re-created?!?
	log files (%ghost was a hack hob to get uucp/hylafax/amanda perms in place)
	*.pyc/*.pyo (these were added to give SELinux a stable/static namespace to attach xattr's)

All of the above should be handled automagically, with explicit
mechanisms, not just by hack-o-round in *.spec endlessly.

Its not like any of the above side-effects isn't very very well understood
and predictable and easily automated in RPM itself, not through endless mind-numbing
*.spec fiddle-ups churn-and-burn. The bikeshed discussions have all been rehashed
so many times that there isn't anything left to talk about, just late arrivals
who haven't quite figgered out what to do.

JMNSHO

73 de Jeff



From qboosh at pld-linux.org  Mon Apr  4 06:58:21 2011
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Mon, 4 Apr 2011 06:58:21 +0200
Subject: python3.2+ compiled files
In-Reply-To: <BANLkTinc-_8KMFFJgQ5w9Lbm7-_91H0R0g@mail.gmail.com>
References: <20110402181118.GA22787@stranger.qboosh.pl>
	<201104022022.25649.arekm@maven.pl>
	<AANLkTi=pF=5wUywx8JRN647im064pubxq8u8M0D7mmSu@mail.gmail.com>
	<BANLkTim7aB=zi9A6TSn7REvpZkR1c-jjgw@mail.gmail.com>
	<BANLkTimEVS5_PeEwgp9fpoKcMOhu1e2Fcw@mail.gmail.com>
	<20110403130419.GA4399@lolek.nigdzie>
	<BANLkTi=DMmohQf6g8ASHxCzgBJ3RihYGpA@mail.gmail.com>
	<268F066B-3BF4-4FC6-B83C-1CB8979F6E2B@mac.com>
	<BANLkTinc-_8KMFFJgQ5w9Lbm7-_91H0R0g@mail.gmail.com>
Message-ID: <20110404045821.GA19242@mail>

On Sun, Apr 03, 2011 at 10:01:32PM +0200, Patryk Zawadzki wrote:
> On Sun, Apr 3, 2011 at 3:27 PM, Jeff Johnson <n3npq at mac.com> wrote:
> > I see a problem with /usr/bin/__pycache__/* and the rest of
> > the python litter on a file system. While __pycache__ subdirs "works" in python's
> > module trees, there will be a litter of __pycache__ subdirs on other
> > paths.
> >
> > But can't a shadow tree (perhaps /var/cache/python/usr/bin/__pycache__/*?) be done?
> 
> That's exactly what I mean, ideally we'd have cached pre-compiled
> files built somewhere in /var/cache for root and ~/.local/cache for
> local files.

Who is going to clean ~/.local/cache for files removed from system?

Also, I'm against compiling python files during installation of rpm package.
Python bytecode depends only on python major.minor (not micro) version,
so there is no reason to do it individually on each target system.
Just like we don't create Java or .NET bytecode at install time.


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


From patrys at pld-linux.org  Mon Apr  4 10:31:26 2011
From: patrys at pld-linux.org (Patryk Zawadzki)
Date: Mon, 4 Apr 2011 10:31:26 +0200
Subject: python3.2+ compiled files
In-Reply-To: <20110404045821.GA19242@mail>
References: <20110402181118.GA22787@stranger.qboosh.pl>
	<201104022022.25649.arekm@maven.pl>
	<AANLkTi=pF=5wUywx8JRN647im064pubxq8u8M0D7mmSu@mail.gmail.com>
	<BANLkTim7aB=zi9A6TSn7REvpZkR1c-jjgw@mail.gmail.com>
	<BANLkTimEVS5_PeEwgp9fpoKcMOhu1e2Fcw@mail.gmail.com>
	<20110403130419.GA4399@lolek.nigdzie>
	<BANLkTi=DMmohQf6g8ASHxCzgBJ3RihYGpA@mail.gmail.com>
	<268F066B-3BF4-4FC6-B83C-1CB8979F6E2B@mac.com>
	<BANLkTinc-_8KMFFJgQ5w9Lbm7-_91H0R0g@mail.gmail.com>
	<20110404045821.GA19242@mail>
Message-ID: <BANLkTik5KGdHscRJqvPW=bLWNSgyBOe5JA@mail.gmail.com>

On Mon, Apr 4, 2011 at 6:58 AM, Jakub Bogusz <qboosh at pld-linux.org> wrote:
> Who is going to clean ~/.local/cache for files removed from system?

Why would _system_ packages end up being compiled to ~/.local/cache?

> Also, I'm against compiling python files during installation of rpm package.
> Python bytecode depends only on python major.minor (not micro) version,
> so there is no reason to do it individually on each target system.
> Just like we don't create Java or .NET bytecode at install time.

With the exception that .NET and Java are virtual machines that
execute bytecode while Python (3.2) is an environment that precompiles
.py files on the fly (with the possibility of caching the results).

-- 
Patryk Zawadzki
I solve problems.


From qboosh at pld-linux.org  Mon Apr  4 15:45:56 2011
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Mon, 4 Apr 2011 15:45:56 +0200
Subject: Bacula 5.0.3 i undefined symbol: my_thread_end
In-Reply-To: <4D99995B.7010102@chabin.eu>
References: <4D99995B.7010102@chabin.eu>
Message-ID: <20110404134555.GA4309@stranger.qboosh.pl>

On Mon, Apr 04, 2011 at 12:11:39PM +0200, Adam Chabin wrote:
> Cze??,
> 
> Mam problem z bacula. Po uruchomieniu joba pod sam jego koniec proces 
> bacula-dir umiera z takim komunikatem:

[bacula-dir dies with:]

> ripley-dir: msgchan.c:362-1004 === End msg_thread. JobId=1004 usecnt=2
> /usr/sbin/bacula-dir: symbol lookup error: /usr/lib/libbacsql-5.0.3.so: 
> undefined symbol: my_thread_end

Some symbol recently unexported from libmysqlclient?


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


From glen at pld-linux.org  Tue Apr  5 09:39:22 2011
From: glen at pld-linux.org (=?ISO-8859-2?Q?Elan_Ruusam=E4e?=)
Date: Tue, 05 Apr 2011 10:39:22 +0300
Subject: Bacula 5.0.3 i undefined symbol: my_thread_end
In-Reply-To: <20110404134555.GA4309@stranger.qboosh.pl>
References: <4D99995B.7010102@chabin.eu>
	<20110404134555.GA4309@stranger.qboosh.pl>
Message-ID: <4D9AC72A.8020501@pld-linux.org>

On 04.04.2011 16:45, Jakub Bogusz wrote:
> On Mon, Apr 04, 2011 at 12:11:39PM +0200, Adam Chabin wrote:
>> Cze??,
>>
>> Mam problem z bacula. Po uruchomieniu joba pod sam jego koniec proces
>> bacula-dir umiera z takim komunikatem:
> [bacula-dir dies with:]
>
>> ripley-dir: msgchan.c:362-1004 === End msg_thread. JobId=1004 usecnt=2
>> /usr/sbin/bacula-dir: symbol lookup error: /usr/lib/libbacsql-5.0.3.so:
>> undefined symbol: my_thread_end
> Some symbol recently unexported from libmysqlclient?
>

5.5 misses version symboling completely, we use version script from fedora

headers for mysql-devel are very poor and apps linked with it too, they 
do not even use correct prototypes

imho we should compile all aps with 
-Werror=implicit-function-declaration and ensure prototypes are present, 
like i did for perl-DBD-mysql

http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/packages/perl-DBD-mysql/perl-DBD-mysql.spec.diff?r1=1.78;r2=1.79;f=h
http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/packages/perl-DBD-mysql/headers.patch?annotate=1.1




-- 
glen



From udvzsolt at gmail.com  Wed Apr  6 09:09:04 2011
From: udvzsolt at gmail.com (Zsolt Udvari)
Date: Wed, 6 Apr 2011 09:09:04 +0200
Subject: Fwd: ERRORS: crossavr-gcc.spec
In-Reply-To: <7305892c-6842-4610-a90b-c60428d8f161@pld.src.builder>
References: <7305892c-6842-4610-a90b-c60428d8f161@pld.src.builder>
Message-ID: <BANLkTimKyksrew=q3_wQGAM5ksH9xK36jg@mail.gmail.com>

Hi all!

I don't know who want to crossavr-gcc but please stop the requesting,
correct the mistake, send again the request. Please check the buildlogs.

Thanks!
  Zsolt


---------- Forwarded message ----------
From: PLD th-src builder <builder-th-src at pld-linux.org>
Date: 2011/4/5
Subject: ERRORS: crossavr-gcc.spec
To: uzsolt at pld-linux.org
Cc: pld-logs-th at lists.pld-linux.org


crossavr-gcc.spec (HEAD): FAILED

--- crossavr-gcc.spec:HEAD:
Build-Time: user:0.34s sys:0.35s real:4.49s (faults io:124 non-io:51626)



*** buildlog for crossavr-gcc.spec
request from: uzsolt
started at: Tue Apr  5 19:10:01 2011
building SRPM using: cd rpm/packages; nice -n 0 ./builder -nu -nm --nodeps
--http -bs  -r HEAD  -Tp auto-th- -tt  crossavr-gcc.spec 2>&1

Can't find java virtual machine, aborting.
U crossavr-gcc/crossavr-gcc.spec
# $Revision: 1.37 $, $Date: 2011/01/30 16:32:36 $

No conditional flags passed

from available:
--with   :       bootstrap
--without:

Available branches: GCC_4_1_1 DEVEL AC-branch
Searching for tag auto-th-crossavr-gcc-4_3_5-1...
Tag auto-th-crossavr-gcc-4_3_5-1 already exists (spec release: 1.37).
exit status 2304
error: No files produced.
Can't find java virtual machine, aborting.
error: Fetching /%{_Rsourcedir}/gcc-4.3.5.tar.bz2 failed: Unknown or
unexpected error
error: Fetching /%{_Rpatchdir}/crossavr-gcc-osmain.patch failed: Unknown or
unexpected error
error: Fetching /%{_Rpatchdir}/crossavr-gcc-xmega.patch failed: Unknown or
unexpected error
error: Fetching /%{_Rpatchdir}/crossavr-gcc-param-inline-call-cost.patch
failed: Unknown or unexpected error
error: Fetching /%{_Rpatchdir}/crossavr-gcc-new-devices.patch failed:
Unknown or unexpected error
error: Fetching /%{_Rpatchdir}/crossavr-gcc-libiberty-Makefile.in.patch
failed: Unknown or unexpected error
error: Fetching /%{_Rpatchdir}/crossavr-gcc-libgcc.patch failed: Unknown or
unexpected error
error: Fetching /%{_Rpatchdir}/crossavr-gcc-builtins-v6.patch failed:
Unknown or unexpected error
error: Fetching /%{_Rpatchdir}/crossavr-gcc-bug-35013.patch failed: Unknown
or unexpected error
error: Fetching /%{_Rpatchdir}/crossavr-gcc-bug-34210-35508.patch failed:
Unknown or unexpected error
error: Fetching /%{_Rpatchdir}/crossavr-gcc-bug-33009.patch failed: Unknown
or unexpected error
error: Fetching
/%{_Rpatchdir}/crossavr-gcc-bug-19636-24894-31644-31786.patch failed:
Unknown or unexpected error
error: Fetching /%{_Rpatchdir}/crossavr-gcc-bug-18145.patch failed: Unknown
or unexpected error
error: Fetching /%{_Rpatchdir}/crossavr-gcc-bug-11259-v3.patch failed:
Unknown or unexpected error
Can't find java virtual machine, aborting.
Begin-PLD-Builder-Info
Build-Time: user:0.34s sys:0.35s real:4.49s (faults io:124 non-io:51626)

End-PLD-Builder-Info


From glen at delfi.ee  Wed Apr  6 09:23:22 2011
From: glen at delfi.ee (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Wed, 06 Apr 2011 10:23:22 +0300
Subject: Fwd: ERRORS: crossavr-gcc.spec
In-Reply-To: <BANLkTimKyksrew=q3_wQGAM5ksH9xK36jg@mail.gmail.com>
References: <7305892c-6842-4610-a90b-c60428d8f161@pld.src.builder>
	<BANLkTimKyksrew=q3_wQGAM5ksH9xK36jg@mail.gmail.com>
Message-ID: <4D9C14EA.4020900@delfi.ee>

what are you talking about?

there is no mistake, error from the log you included says, that exsting 
build already done (tag on NVR exists):

Tag auto-th-crossavr-gcc-4_3_5-1 already exists (spec release: 1.37).

and the requester is you yourself:

*** buildlog for crossavr-gcc.spec
request from: uzsolt
started at: Tue Apr  5 19:10:01 2011


so, uzsolt, check the buildlogs before shouting!

On 06.04.2011 10:09, Zsolt Udvari wrote:
> Hi all!
>
> I don't know who want to crossavr-gcc but please stop the requesting,
> correct the mistake, send again the request. Please check the buildlogs.
>
> Thanks!
>    Zsolt
>
>
> ---------- Forwarded message ----------
> From: PLD th-src builder<builder-th-src at pld-linux.org>
> Date: 2011/4/5
> Subject: ERRORS: crossavr-gcc.spec
> To: uzsolt at pld-linux.org
> Cc: pld-logs-th at lists.pld-linux.org
>
>
> crossavr-gcc.spec (HEAD): FAILED
>
> --- crossavr-gcc.spec:HEAD:
> Build-Time: user:0.34s sys:0.35s real:4.49s (faults io:124 non-io:51626)
>
>
>
> *** buildlog for crossavr-gcc.spec
> request from: uzsolt
> started at: Tue Apr  5 19:10:01 2011
> building SRPM using: cd rpm/packages; nice -n 0 ./builder -nu -nm --nodeps
> --http -bs  -r HEAD  -Tp auto-th- -tt  crossavr-gcc.spec 2>&1
>
> Can't find java virtual machine, aborting.
> U crossavr-gcc/crossavr-gcc.spec
> # $Revision: 1.37 $, $Date: 2011/01/30 16:32:36 $
>
> No conditional flags passed
>
> from available:
> --with   :       bootstrap
> --without:
>
> Available branches: GCC_4_1_1 DEVEL AC-branch
> Searching for tag auto-th-crossavr-gcc-4_3_5-1...
> Tag auto-th-crossavr-gcc-4_3_5-1 already exists (spec release: 1.37).
> exit status 2304
> error: No files produced.
> Can't find java virtual machine, aborting.
> error: Fetching /%{_Rsourcedir}/gcc-4.3.5.tar.bz2 failed: Unknown or
> unexpected error
> error: Fetching /%{_Rpatchdir}/crossavr-gcc-osmain.patch failed: Unknown or
> unexpected error
> error: Fetching /%{_Rpatchdir}/crossavr-gcc-xmega.patch failed: Unknown or
> unexpected error
> error: Fetching /%{_Rpatchdir}/crossavr-gcc-param-inline-call-cost.patch
> failed: Unknown or unexpected error
> error: Fetching /%{_Rpatchdir}/crossavr-gcc-new-devices.patch failed:
> Unknown or unexpected error
> error: Fetching /%{_Rpatchdir}/crossavr-gcc-libiberty-Makefile.in.patch
> failed: Unknown or unexpected error
> error: Fetching /%{_Rpatchdir}/crossavr-gcc-libgcc.patch failed: Unknown or
> unexpected error
> error: Fetching /%{_Rpatchdir}/crossavr-gcc-builtins-v6.patch failed:
> Unknown or unexpected error
> error: Fetching /%{_Rpatchdir}/crossavr-gcc-bug-35013.patch failed: Unknown
> or unexpected error
> error: Fetching /%{_Rpatchdir}/crossavr-gcc-bug-34210-35508.patch failed:
> Unknown or unexpected error
> error: Fetching /%{_Rpatchdir}/crossavr-gcc-bug-33009.patch failed: Unknown
> or unexpected error
> error: Fetching
> /%{_Rpatchdir}/crossavr-gcc-bug-19636-24894-31644-31786.patch failed:
> Unknown or unexpected error
> error: Fetching /%{_Rpatchdir}/crossavr-gcc-bug-18145.patch failed: Unknown
> or unexpected error
> error: Fetching /%{_Rpatchdir}/crossavr-gcc-bug-11259-v3.patch failed:
> Unknown or unexpected error
> Can't find java virtual machine, aborting.
> Begin-PLD-Builder-Info
> Build-Time: user:0.34s sys:0.35s real:4.49s (faults io:124 non-io:51626)
>
> End-PLD-Builder-Info
> _______________________________________________
> pld-devel-en mailing list
> pld-devel-en at lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


-- 
glen



From udvzsolt at gmail.com  Wed Apr  6 10:43:13 2011
From: udvzsolt at gmail.com (Zsolt Udvari)
Date: Wed, 6 Apr 2011 10:43:13 +0200
Subject: Fwd: ERRORS: crossavr-gcc.spec
In-Reply-To: <4D9C14EA.4020900@delfi.ee>
References: <7305892c-6842-4610-a90b-c60428d8f161@pld.src.builder>
	<BANLkTimKyksrew=q3_wQGAM5ksH9xK36jg@mail.gmail.com>
	<4D9C14EA.4020900@delfi.ee>
Message-ID: <BANLkTi=duCHTDXTqM=X2NOzhQei07wEtUw@mail.gmail.com>

Ok, understand, but I received many (many=5) request by stbr:
4 april, 18:00
5 april, 2:00
5 april, 3:00
5 april, 13:00
6 april 1:00

Hm. now I see. Is it maybe an automatic request?


2011/4/6 Elan Ruusam?e <glen at delfi.ee>

> what are you talking about?
>
> there is no mistake, error from the log you included says, that exsting
> build already done (tag on NVR exists):
>
>
> Tag auto-th-crossavr-gcc-4_3_5-1 already exists (spec release: 1.37).
>
> and the requester is you yourself:
>
>
> *** buildlog for crossavr-gcc.spec
> request from: uzsolt
> started at: Tue Apr  5 19:10:01 2011
>
>
> so, uzsolt, check the buildlogs before shouting!
>
>
> On 06.04.2011 10:09, Zsolt Udvari wrote:
>
>> Hi all!
>>
>> I don't know who want to crossavr-gcc but please stop the requesting,
>> correct the mistake, send again the request. Please check the buildlogs.
>>
>> Thanks!
>>   Zsolt
>>
>>
>> ---------- Forwarded message ----------
>> From: PLD th-src builder<builder-th-src at pld-linux.org>
>> Date: 2011/4/5
>> Subject: ERRORS: crossavr-gcc.spec
>> To: uzsolt at pld-linux.org
>> Cc: pld-logs-th at lists.pld-linux.org
>>
>>
>> crossavr-gcc.spec (HEAD): FAILED
>>
>> --- crossavr-gcc.spec:HEAD:
>> Build-Time: user:0.34s sys:0.35s real:4.49s (faults io:124 non-io:51626)
>>
>>
>>
>> *** buildlog for crossavr-gcc.spec
>> request from: uzsolt
>> started at: Tue Apr  5 19:10:01 2011
>> building SRPM using: cd rpm/packages; nice -n 0 ./builder -nu -nm --nodeps
>> --http -bs  -r HEAD  -Tp auto-th- -tt  crossavr-gcc.spec 2>&1
>>
>> Can't find java virtual machine, aborting.
>> U crossavr-gcc/crossavr-gcc.spec
>> # $Revision: 1.37 $, $Date: 2011/01/30 16:32:36 $
>>
>> No conditional flags passed
>>
>> from available:
>> --with   :       bootstrap
>> --without:
>>
>> Available branches: GCC_4_1_1 DEVEL AC-branch
>> Searching for tag auto-th-crossavr-gcc-4_3_5-1...
>> Tag auto-th-crossavr-gcc-4_3_5-1 already exists (spec release: 1.37).
>> exit status 2304
>> error: No files produced.
>> Can't find java virtual machine, aborting.
>> error: Fetching /%{_Rsourcedir}/gcc-4.3.5.tar.bz2 failed: Unknown or
>> unexpected error
>> error: Fetching /%{_Rpatchdir}/crossavr-gcc-osmain.patch failed: Unknown
>> or
>> unexpected error
>> error: Fetching /%{_Rpatchdir}/crossavr-gcc-xmega.patch failed: Unknown or
>> unexpected error
>> error: Fetching /%{_Rpatchdir}/crossavr-gcc-param-inline-call-cost.patch
>> failed: Unknown or unexpected error
>> error: Fetching /%{_Rpatchdir}/crossavr-gcc-new-devices.patch failed:
>> Unknown or unexpected error
>> error: Fetching /%{_Rpatchdir}/crossavr-gcc-libiberty-Makefile.in.patch
>> failed: Unknown or unexpected error
>> error: Fetching /%{_Rpatchdir}/crossavr-gcc-libgcc.patch failed: Unknown
>> or
>> unexpected error
>> error: Fetching /%{_Rpatchdir}/crossavr-gcc-builtins-v6.patch failed:
>> Unknown or unexpected error
>> error: Fetching /%{_Rpatchdir}/crossavr-gcc-bug-35013.patch failed:
>> Unknown
>> or unexpected error
>> error: Fetching /%{_Rpatchdir}/crossavr-gcc-bug-34210-35508.patch failed:
>> Unknown or unexpected error
>> error: Fetching /%{_Rpatchdir}/crossavr-gcc-bug-33009.patch failed:
>> Unknown
>> or unexpected error
>> error: Fetching
>> /%{_Rpatchdir}/crossavr-gcc-bug-19636-24894-31644-31786.patch failed:
>> Unknown or unexpected error
>> error: Fetching /%{_Rpatchdir}/crossavr-gcc-bug-18145.patch failed:
>> Unknown
>> or unexpected error
>> error: Fetching /%{_Rpatchdir}/crossavr-gcc-bug-11259-v3.patch failed:
>> Unknown or unexpected error
>> Can't find java virtual machine, aborting.
>> Begin-PLD-Builder-Info
>> Build-Time: user:0.34s sys:0.35s real:4.49s (faults io:124 non-io:51626)
>>
>> End-PLD-Builder-Info
>> _______________________________________________
>> pld-devel-en mailing list
>> pld-devel-en at lists.pld-linux.org
>> http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
>>
>
>
> --
> glen
>
>


From pawel at dlugosz.eu  Wed Apr  6 10:46:40 2011
From: pawel at dlugosz.eu (Pawel Dlugosz)
Date: Wed, 06 Apr 2011 10:46:40 +0200
Subject: Fwd: ERRORS: crossavr-gcc.spec
In-Reply-To: <BANLkTi=duCHTDXTqM=X2NOzhQei07wEtUw@mail.gmail.com>
References: <7305892c-6842-4610-a90b-c60428d8f161@pld.src.builder>	<BANLkTimKyksrew=q3_wQGAM5ksH9xK36jg@mail.gmail.com>	<4D9C14EA.4020900@delfi.ee>
	<BANLkTi=duCHTDXTqM=X2NOzhQei07wEtUw@mail.gmail.com>
Message-ID: <4D9C2870.7040704@dlugosz.eu>

On 06.04.2011 10:43, Zsolt Udvari wrote:
> Ok, understand, but I received many (many=5) request by stbr:
> 4 april, 18:00
> 5 april, 2:00
> 5 april, 3:00
> 5 april, 13:00
> 6 april 1:00
>
> Hm. now I see. Is it maybe an automatic request?

Just a small glitch in the matrix. Don't worry, should be fixed by now.

-- 
Pawe? <@duddits> D?ugosz
.::http://dlugosz.eu::.


From glen at pld-linux.org  Fri Apr  8 21:22:30 2011
From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Fri, 08 Apr 2011 22:22:30 +0300
Subject: packages: squid/squid.spec - up to 3.1.12 by Marcin Rybak
	<marcin.rybak<#>g...
In-Reply-To: <packages_squid_squid.spec.1.330@pld-linux.org>
References: <packages_squid_squid.spec.1.329@pld-linux.org>
	<packages_squid_squid.spec.1.330@pld-linux.org>
Message-ID: <4D9F6076.9070605@pld-linux.org>

On 08/04/11 20:27, baggins wrote:
> +%lang(op) %{_datadir}/squid/errors/oc

this %lang(op) for oc dir is correct? or typo? (too lazy to check the 
contents)

-- 
glen


From marcin.rybak at gmail.com  Fri Apr  8 21:48:31 2011
From: marcin.rybak at gmail.com (Marcin Rybak)
Date: Fri, 8 Apr 2011 19:48:31 +0000
Subject: packages: squid/squid.spec - up to 3.1.12 by Marcin
	Rybak<marcin.rybak<#>g...
Message-ID: <31030518-1302292110-cardhu_decombobulator_blackberry.rim.net-747108012-@b14.c8.bise7.blackberry>

U r right, spell error, sorry
Marcin
------Original Message------
From: Elan Ruusam?e
Sender: pld-devel-en-bounces at lists.pld-linux.org
To: pld-devel-pl at lists.pld-linux.org
To: pld-devel-en at lists.pld-linux.org
Cc: baggins
ReplyTo: PLD: Developers list \(English\)
Subject: Re: packages: squid/squid.spec - up to 3.1.12 by Marcin Rybak<marcin.rybak<#>g...
Sent: Apr 8, 2011 9:22 PM

On 08/04/11 20:27, baggins wrote:
> +%lang(op) %{_datadir}/squid/errors/oc

this %lang(op) for oc dir is correct? or typo? (too lazy to check the 
contents)

-- 
glen
_______________________________________________
pld-devel-en mailing list
pld-devel-en at lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


---
Marcin Rybak
http://marcinrybak.com

Sent from BlackBerry?

From patrys at pld-linux.org  Sat Apr  9 01:58:04 2011
From: patrys at pld-linux.org (Patryk Zawadzki)
Date: Sat, 9 Apr 2011 01:58:04 +0200
Subject: packages: squid/squid.spec - up to 3.1.12 by Marcin
	Rybak<marcin.rybak<#>g...
In-Reply-To: <31030518-1302292110-cardhu_decombobulator_blackberry.rim.net-747108012-@b14.c8.bise7.blackberry>
References: <31030518-1302292110-cardhu_decombobulator_blackberry.rim.net-747108012-@b14.c8.bise7.blackberry>
Message-ID: <BANLkTimEeYn6WjB5SgBZoO_5E-ydBCqv=Q@mail.gmail.com>

On Fri, Apr 8, 2011 at 9:48 PM, Marcin Rybak <marcin.rybak at gmail.com> wrote:
> U r right, spell error, sorry

Two spelling errors above, the word you are looking for are "you" and "are".

-- 
Patryk Zawadzki
I solve problems.


From glen at pld-linux.org  Sat Apr  9 14:31:47 2011
From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Sat, 09 Apr 2011 15:31:47 +0300
Subject: python3.2+ compiled files
In-Reply-To: <20110402181118.GA22787@stranger.qboosh.pl>
References: <20110402181118.GA22787@stranger.qboosh.pl>
Message-ID: <4DA051B3.6090705@pld-linux.org>

On 02/04/11 21:11, Jakub Bogusz wrote:
> It seems that since python 3.2 upstream changed the default way
> of creating compiled files: instead of *.pyc/*.pyo in the same
> directory that .py file exists, the compiled files are created
> in __pycache__ subdirectory.
> According to some googled information, the "old method" (files created
> in the same directory by compileall) still works in the same way.
> In case of the "new method", compiled files are searched in __pycache__
> subdirectory only if source file exists.
>
> I'm not sure if the new method affects only (c)python 3.2 installation,
> or all modules installed using distutils or so.
>
> So we have to decide how to package python distribution (and possibly
> all python3 modules, if distutils use __pycache__ too) - there are
> two solutions:
>
> - package all modules in source form together with __pycache__
>    subdirectories
>
> - stick to "old way" - manually py_comp/py_ocomp all python files,
>    package *.py[co] without using __pycache__ subdirectories
>

i always liked the pld way of packaing only .pyc/.pyo for runtime

so my vote goes for keeping the old .py[co] method, and perhaps change 
to make is package only .pyc, it is rather ratre somebody invokes python 
with -O option so the .pyo is to be needed. or why it was packaged in 
first place? to get files owned in case somebody invokes as root and 
.pyo gets created? perhaps package .pyc as regular files and .pyo as 
ghosted then.

also, python supports bundling the libraries as .zip files too, what 
about that approach :)

$ strace -ff -efile python -c "import os" 2>&1|grep .zip
stat64("/usr/lib/python27.zip", 0xbff4e97c) = -1 ENOENT (No such file or 
directory)
stat64("/usr/lib/python27.zip", 0xbff4e97c) = -1 ENOENT (No such file or 
directory)

as for the .py sources packaging, i'd move them to -debuginfo package so 
the could be installed optionally

-- 
glen


From patrys at pld-linux.org  Sat Apr  9 20:13:43 2011
From: patrys at pld-linux.org (Patryk Zawadzki)
Date: Sat, 9 Apr 2011 20:13:43 +0200
Subject: python3.2+ compiled files
In-Reply-To: <4DA051B3.6090705@pld-linux.org>
References: <20110402181118.GA22787@stranger.qboosh.pl>
	<4DA051B3.6090705@pld-linux.org>
Message-ID: <BANLkTinDoT5eB=4q0U07i8+Szkvh0Sqe=A@mail.gmail.com>

2011/4/9 Elan Ruusam?e <glen at pld-linux.org>:
> so my vote goes for keeping the old .py[co] method, and perhaps change to
> make is package only .pyc, it is rather ratre somebody invokes python with
> -O option so the .pyo is to be needed. or why it was packaged in first
> place? to get files owned in case somebody invokes as root and .pyo gets
> created? perhaps package .pyc as regular files and .pyo as ghosted then.

Not sure about PLD but I suppose we just followed what the others were
doing. Other distros did it this way so they could set proper selinux
attributes.

-- 
Patryk Zawadzki
I solve problems.


From baggins at pld-linux.org  Sat Apr  9 21:03:44 2011
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Sat, 9 Apr 2011 21:03:44 +0200
Subject: python3.2+ compiled files
In-Reply-To: <4DA051B3.6090705@pld-linux.org>
References: <20110402181118.GA22787@stranger.qboosh.pl>
	<4DA051B3.6090705@pld-linux.org>
Message-ID: <20110409190344.GA2636@home.lan>

On Sat, 09 Apr 2011, Elan Ruusam?e wrote:

> as for the .py sources packaging, i'd move them to -debuginfo package so 
> the could be installed optionally

Are you aware that some python apps do runtime feature checking and
setting based od the presence of .py files? That those apps can't live
without them? python-numpy being an example.

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


From n3npq at mac.com  Sat Apr  9 21:26:46 2011
From: n3npq at mac.com (Jeff Johnson)
Date: Sat, 09 Apr 2011 15:26:46 -0400
Subject: python3.2+ compiled files
In-Reply-To: <BANLkTinDoT5eB=4q0U07i8+Szkvh0Sqe=A@mail.gmail.com>
References: <20110402181118.GA22787@stranger.qboosh.pl>
	<4DA051B3.6090705@pld-linux.org>
	<BANLkTinDoT5eB=4q0U07i8+Szkvh0Sqe=A@mail.gmail.com>
Message-ID: <31BC6DFF-905F-4B2B-8676-A06731BFD475@mac.com>


On Apr 9, 2011, at 2:13 PM, Patryk Zawadzki wrote:

> 2011/4/9 Elan Ruusam?e <glen at pld-linux.org>:
>> so my vote goes for keeping the old .py[co] method, and perhaps change to
>> make is package only .pyc, it is rather ratre somebody invokes python with
>> -O option so the .pyo is to be needed. or why it was packaged in first
>> place? to get files owned in case somebody invokes as root and .pyo gets
>> created? perhaps package .pyc as regular files and .pyo as ghosted then.
> 
> Not sure about PLD but I suppose we just followed what the others were
> doing. Other distros did it this way so they could set proper selinux
> attributes.
> 

Yes. Attaching SElinux xattr's to 1+ M paths forced *.pyo to be included
everywhere/always in *.rpm.

That *was* 5+ years ago. There's no known reason why xattr's can't be done
in other ways. In fact SELinux does relabeling outside of rpm these
days, there's literally no reason that *.pyo MUST be included in *.rpm
5+ years later.

And 5+ years later SELinux hasn't really achieved the wide deployment desired,
packaging *.pyc and adapting to changing conventions in pyton > 3.2 wasn't
even conceivable 5+ years ago.

73 de Jeff

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4645 bytes
Desc: not available
URL: </mailman/pipermail/pld-devel-en/attachments/20110409/8578a3a3/attachment.p7s>

From gotar at polanet.pl  Sat Apr  9 21:29:33 2011
From: gotar at polanet.pl (Tomasz Pala)
Date: Sat, 9 Apr 2011 21:29:33 +0200
Subject: python3.2+ compiled files
In-Reply-To: <31BC6DFF-905F-4B2B-8676-A06731BFD475@mac.com>
References: <20110402181118.GA22787@stranger.qboosh.pl>
	<4DA051B3.6090705@pld-linux.org>
	<BANLkTinDoT5eB=4q0U07i8+Szkvh0Sqe=A@mail.gmail.com>
	<31BC6DFF-905F-4B2B-8676-A06731BFD475@mac.com>
Message-ID: <20110409192933.GA1644@polanet.pl>

On Sat, Apr 09, 2011 at 15:26:46 -0400, Jeff Johnson wrote:

> There's no known reason why xattr's can't be done in other ways.

Like what?

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


From n3npq at mac.com  Sat Apr  9 21:34:55 2011
From: n3npq at mac.com (Jeff Johnson)
Date: Sat, 09 Apr 2011 15:34:55 -0400
Subject: python3.2+ compiled files
In-Reply-To: <20110409192933.GA1644@polanet.pl>
References: <20110402181118.GA22787@stranger.qboosh.pl>
	<4DA051B3.6090705@pld-linux.org>
	<BANLkTinDoT5eB=4q0U07i8+Szkvh0Sqe=A@mail.gmail.com>
	<31BC6DFF-905F-4B2B-8676-A06731BFD475@mac.com>
	<20110409192933.GA1644@polanet.pl>
Message-ID: <079E859F-6FA0-4060-B9F1-5D94E5BC9E0B@mac.com>


On Apr 9, 2011, at 3:29 PM, Tomasz Pala wrote:

> On Sat, Apr 09, 2011 at 15:26:46 -0400, Jeff Johnson wrote:
> 
>> There's no known reason why xattr's can't be done in other ways.
> 
> Like what?
> 

Like not having RPM attach xattr's. 5+ years ago, I had
to swipe a hunk of code from libselinux and get things done
because the SELinux trolls hadn't written reliable tools yet.

Like patching python to attach xattr's dynamically. The ruke
5+ years ago was
	The application that creates the files needs to ensure
	that the xattr's are attached.
The trolls wussed out with python+selinux patches.

And note python eggs dynamically downloaded. Why oh why
should a sensible and intuitive and rapid upgrade be
forced back into *.rpm static content for no other reason
than the SELinux trolls wussed out on a patch, thereby
avoiding their own rather Draconian implementation rule,
5+ years ago?!?

73 de Jeff

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4645 bytes
Desc: not available
URL: </mailman/pipermail/pld-devel-en/attachments/20110409/4afec50a/attachment.p7s>

From gotar at polanet.pl  Sat Apr  9 21:50:18 2011
From: gotar at polanet.pl (Tomasz Pala)
Date: Sat, 9 Apr 2011 21:50:18 +0200
Subject: python3.2+ compiled files
In-Reply-To: <079E859F-6FA0-4060-B9F1-5D94E5BC9E0B@mac.com>
References: <20110402181118.GA22787@stranger.qboosh.pl>
	<4DA051B3.6090705@pld-linux.org>
	<BANLkTinDoT5eB=4q0U07i8+Szkvh0Sqe=A@mail.gmail.com>
	<31BC6DFF-905F-4B2B-8676-A06731BFD475@mac.com>
	<20110409192933.GA1644@polanet.pl>
	<079E859F-6FA0-4060-B9F1-5D94E5BC9E0B@mac.com>
Message-ID: <20110409195018.GB1644@polanet.pl>

On Sat, Apr 09, 2011 at 15:34:55 -0400, Jeff Johnson wrote:

>>> There's no known reason why xattr's can't be done in other ways.
>> 
>> Like what?
> 
> Like not having RPM attach xattr's.

Please tell me how to do root-free (capabilities-based) system without
xattrs in rpm - doing this outside upgrade procedure leaves window for
making system unusable in cases like power failure.

Now we're using some dumb solutions like 'admin' group for SUID ICMP ping
instead attaching proper file capabilities. In long term we should
remove ALL SUID binaries from distribution, as this approach is broken
by design and should be obsoleted 10 years ago.

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


From n3npq at mac.com  Sat Apr  9 21:56:04 2011
From: n3npq at mac.com (Jeff Johnson)
Date: Sat, 09 Apr 2011 15:56:04 -0400
Subject: python3.2+ compiled files
In-Reply-To: <20110409195018.GB1644@polanet.pl>
References: <20110402181118.GA22787@stranger.qboosh.pl>
	<4DA051B3.6090705@pld-linux.org>
	<BANLkTinDoT5eB=4q0U07i8+Szkvh0Sqe=A@mail.gmail.com>
	<31BC6DFF-905F-4B2B-8676-A06731BFD475@mac.com>
	<20110409192933.GA1644@polanet.pl>
	<079E859F-6FA0-4060-B9F1-5D94E5BC9E0B@mac.com>
	<20110409195018.GB1644@polanet.pl>
Message-ID: <069BCEEF-7737-44D3-8808-58AB33F6295F@mac.com>


On Apr 9, 2011, at 3:50 PM, Tomasz Pala wrote:

> On Sat, Apr 09, 2011 at 15:34:55 -0400, Jeff Johnson wrote:
> 
>>>> There's no known reason why xattr's can't be done in other ways.
>>> 
>>> Like what?
>> 
>> Like not having RPM attach xattr's.
> 
> Please tell me how to do root-free (capabilities-based) system without
> xattrs in rpm - doing this outside upgrade procedure leaves window for
> making system unusable in cases like power failure.
> 

You asked for me to explain "other ways". I am not obligated
nor inclined to argue security packaging with anyone in public.
I quite well know what *I* would do instead; but the issue here is
what *you* want to do in PLD.

> Now we're using some dumb solutions like 'admin' group for SUID ICMP ping
> instead attaching proper file capabilities. In long term we should
> remove ALL SUID binaries from distribution, as this approach is broken
> by design and should be obsoleted 10 years ago.
> 

That is your right and privilege to do whatever you wish to do.

But unlike other dstros, PLD usually does sensible engineering.

The only reason I replied is because Patryk said:

> Not sure about PLD but I suppose we just followed what the others were
> doing. Other distros did it this way so they could set proper selinux
> attributes.

basically arguing "Do what everyone else is doing." when the
reality is actually that SELinux wussed out on proper engineering
5+ years ago (and is considerably improved since).

73 de Jeff

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4645 bytes
Desc: not available
URL: </mailman/pipermail/pld-devel-en/attachments/20110409/e7bee8e2/attachment.p7s>

From gotar at polanet.pl  Sat Apr  9 22:16:12 2011
From: gotar at polanet.pl (Tomasz Pala)
Date: Sat, 9 Apr 2011 22:16:12 +0200
Subject: python3.2+ compiled files
In-Reply-To: <069BCEEF-7737-44D3-8808-58AB33F6295F@mac.com>
References: <20110402181118.GA22787@stranger.qboosh.pl>
	<4DA051B3.6090705@pld-linux.org>
	<BANLkTinDoT5eB=4q0U07i8+Szkvh0Sqe=A@mail.gmail.com>
	<31BC6DFF-905F-4B2B-8676-A06731BFD475@mac.com>
	<20110409192933.GA1644@polanet.pl>
	<079E859F-6FA0-4060-B9F1-5D94E5BC9E0B@mac.com>
	<20110409195018.GB1644@polanet.pl>
	<069BCEEF-7737-44D3-8808-58AB33F6295F@mac.com>
Message-ID: <20110409201612.GA6403@polanet.pl>

On Sat, Apr 09, 2011 at 15:56:04 -0400, Jeff Johnson wrote:

>>>>> There's no known reason why xattr's can't be done in other ways.
>>>> 
>>>> Like what?
>>> 
>>> Like not having RPM attach xattr's.
>> 
>> Please tell me how to do root-free (capabilities-based) system without
>> xattrs in rpm - doing this outside upgrade procedure leaves window for
>> making system unusable in cases like power failure.
> 
> You asked for me to explain "other ways".

And I've shown that this "way" is wrong - having xattrs outside package
manager is bad design per se.

> I am not obligated
> nor inclined to argue security packaging with anyone in public.
> I quite well know what *I* would do instead; but the issue here is
> what *you* want to do in PLD.

I want to get rid of SUID. If you know how to do this - please tell. The
only way I'm aware is by storing xattrs in rpm packages either directly
or by some mechanism bound tightly to upgrade procedure (I don't know
rpm internals if that's possible now).

>> Now we're using some dumb solutions like 'admin' group for SUID ICMP ping
>> instead attaching proper file capabilities. In long term we should
>> remove ALL SUID binaries from distribution, as this approach is broken
>> by design and should be obsoleted 10 years ago.
> 
> That is your right and privilege to do whatever you wish to do.

So how can I store these caps in rpm? Or force rpm not to overwrite
these set by me in filesystem (manually or by other tool)?

>> Not sure about PLD but I suppose we just followed what the others were
>> doing. Other distros did it this way so they could set proper selinux
>> attributes.
> 
> basically arguing "Do what everyone else is doing." when the
> reality is actually that SELinux wussed out on proper engineering
> 5+ years ago (and is considerably improved since).

I'm not referring to SELinux, it's overcomplicated for most of the
people. Unlike xattrs, which ARE contemporary replacement of ancient
file permissions (ACL) and authorization management (capabilities).

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


From n3npq at mac.com  Sat Apr  9 22:32:01 2011
From: n3npq at mac.com (Jeff Johnson)
Date: Sat, 09 Apr 2011 16:32:01 -0400
Subject: python3.2+ compiled files
In-Reply-To: <20110409201612.GA6403@polanet.pl>
References: <20110402181118.GA22787@stranger.qboosh.pl>
	<4DA051B3.6090705@pld-linux.org>
	<BANLkTinDoT5eB=4q0U07i8+Szkvh0Sqe=A@mail.gmail.com>
	<31BC6DFF-905F-4B2B-8676-A06731BFD475@mac.com>
	<20110409192933.GA1644@polanet.pl>
	<079E859F-6FA0-4060-B9F1-5D94E5BC9E0B@mac.com>
	<20110409195018.GB1644@polanet.pl>
	<069BCEEF-7737-44D3-8808-58AB33F6295F@mac.com>
	<20110409201612.GA6403@polanet.pl>
Message-ID: <234FE8AB-9FB5-433E-B6B5-4ADCBF2FAB9B@mac.com>


On Apr 9, 2011, at 4:16 PM, Tomasz Pala wrote:

> On Sat, Apr 09, 2011 at 15:56:04 -0400, Jeff Johnson wrote:
> 
>>>>>> There's no known reason why xattr's can't be done in other ways.
>>>>> 
>>>>> Like what?
>>>> 
>>>> Like not having RPM attach xattr's.
>>> 
>>> Please tell me how to do root-free (capabilities-based) system without
>>> xattrs in rpm - doing this outside upgrade procedure leaves window for
>>> making system unusable in cases like power failure.
>> 
>> You asked for me to explain "other ways".
> 
> And I've shown that this "way" is wrong - having xattrs outside package
> manager is bad design per se.
> 

You WILL have users using python eggs, and there WILL be a window
installing content outside of package management.

Similarly true for CPAN and ruby gems and whatever PHP
and JavaScript are doing.

The approach in SELinux is inheirited xattr's from well known directories.

None of the above involves rpm "package management" installing xattr's.

And none of the above precludes rpm from attaching xattr's where it makes sense.
This thread started -- not about secuirity -- but how to handle
*.pyo side effects.

>> I am not obligated
>> nor inclined to argue security packaging with anyone in public.
>> I quite well know what *I* would do instead; but the issue here is
>> what *you* want to do in PLD.
> 
> I want to get rid of SUID. If you know how to do this - please tell. The
> only way I'm aware is by storing xattrs in rpm packages either directly
> or by some mechanism bound tightly to upgrade procedure (I don't know
> rpm internals if that's possible now).
> 

SO get rid of SUID. What SUID has to do with "package management" of
*.pyo side-effects isn't clear.

>>> Now we're using some dumb solutions like 'admin' group for SUID ICMP ping
>>> instead attaching proper file capabilities. In long term we should
>>> remove ALL SUID binaries from distribution, as this approach is broken
>>> by design and should be obsoleted 10 years ago.
>> 
>> That is your right and privilege to do whatever you wish to do.
> 
> So how can I store these caps in rpm? Or force rpm not to overwrite
> these set by me in filesystem (manually or by other tool)?
> 

How does rpm store data in an rpmdb? You look at the schema,
you create records conistent with the schema, and you write
tools to make that happen for other data.

Reasoning from "RPM has a database" -> "All content MUST be delivered
in *.rpm packages" -> "I want to remove SUID's!" is rather muddled.

>>> Not sure about PLD but I suppose we just followed what the others were
>>> doing. Other distros did it this way so they could set proper selinux
>>> attributes.
>> 
>> basically arguing "Do what everyone else is doing." when the
>> reality is actually that SELinux wussed out on proper engineering
>> 5+ years ago (and is considerably improved since).
> 
> I'm not referring to SELinux, it's overcomplicated for most of the
> people. Unlike xattrs, which ARE contemporary replacement of ancient
> file permissions (ACL) and authorization management (capabilities).
> 

And this thread started (see Subject:) with

	What should be done with python's Newer! Better! Bestest!
	convention for storing compiled *.pyo files?

not anything else.

And all I wished to point out is the (rather flawed imho) reasoning
that led to putting *.pyo files into *.rpm packages so that
SELinux trolls could pretend to a solution based on security tags
instantiated in xattr's.

73 de Jeff

73 de Jeff
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4645 bytes
Desc: not available
URL: </mailman/pipermail/pld-devel-en/attachments/20110409/5ac75fc7/attachment.p7s>

From gotar at polanet.pl  Sat Apr  9 22:52:54 2011
From: gotar at polanet.pl (Tomasz Pala)
Date: Sat, 9 Apr 2011 22:52:54 +0200
Subject: python3.2+ compiled files
In-Reply-To: <234FE8AB-9FB5-433E-B6B5-4ADCBF2FAB9B@mac.com>
References: <20110402181118.GA22787@stranger.qboosh.pl>
	<4DA051B3.6090705@pld-linux.org>
	<BANLkTinDoT5eB=4q0U07i8+Szkvh0Sqe=A@mail.gmail.com>
	<31BC6DFF-905F-4B2B-8676-A06731BFD475@mac.com>
	<20110409192933.GA1644@polanet.pl>
	<079E859F-6FA0-4060-B9F1-5D94E5BC9E0B@mac.com>
	<20110409195018.GB1644@polanet.pl>
	<069BCEEF-7737-44D3-8808-58AB33F6295F@mac.com>
	<20110409201612.GA6403@polanet.pl>
	<234FE8AB-9FB5-433E-B6B5-4ADCBF2FAB9B@mac.com>
Message-ID: <20110409205254.GB6403@polanet.pl>

On Sat, Apr 09, 2011 at 16:32:01 -0400, Jeff Johnson wrote:

>> And I've shown that this "way" is wrong - having xattrs outside package
>> manager is bad design per se.
> 
> You WILL have users using python eggs, and there WILL be a window
> installing content outside of package management.

And how is this related to storing xattrs?

[...]
> None of the above involves rpm "package management" installing xattr's.

Exactly - so don't throw me with arguments I do not care at all. I say
rpm should handle xattrs, nothing more.

> And none of the above precludes rpm from attaching xattr's where it makes sense.
> This thread started -- not about secuirity -- but how to handle
> *.pyo side effects.

I have no idea and I really do not care a bit. What I do know is that
application level is less important than system level, and the latter
requires xattrs in modern package management system.
How do we use them THEN, it's another issue.

> SO get rid of SUID.

I can't - rpm doesn't support xattrs (or it's so top secret you can't
tell me how to do this).

> What SUID has to do with "package management" of
> *.pyo side-effects isn't clear.

Did I mention some pyo somewhere?

>> So how can I store these caps in rpm? Or force rpm not to overwrite
>> these set by me in filesystem (manually or by other tool)?
> 
> How does rpm store data in an rpmdb? You look at the schema,
> you create records conistent with the schema, and you write
> tools to make that happen for other data.

Thanks, that really helps. You could just write 'create your own package
manager'.

> Reasoning from "RPM has a database" -> "All content MUST be delivered
> in *.rpm packages" -> "I want to remove SUID's!" is rather muddled.

No. "RPM delivers content with SUIDs instead of ACLs/caps" -> "RPM
should be fixed to handle xattrs".

> And this thread started (see Subject:) with
> 
> 	What should be done with python's Newer! Better! Bestest!
> 	convention for storing compiled *.pyo files?
> 
> not anything else.

It started like this, I've added something else. That is how discussions
work, subject doesn't have to be fixed as nobody has to stick the first mail
only.

> And all I wished to point out is the (rather flawed imho) reasoning
> that led to putting *.pyo files into *.rpm packages so that
> SELinux trolls could pretend to a solution based on security tags
> instantiated in xattr's.

Maybe, don't know, don't care, won't argue.

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


From n3npq at mac.com  Sat Apr  9 23:09:54 2011
From: n3npq at mac.com (Jeff Johnson)
Date: Sat, 09 Apr 2011 17:09:54 -0400
Subject: python3.2+ compiled files
In-Reply-To: <20110409205254.GB6403@polanet.pl>
References: <20110402181118.GA22787@stranger.qboosh.pl>
	<4DA051B3.6090705@pld-linux.org>
	<BANLkTinDoT5eB=4q0U07i8+Szkvh0Sqe=A@mail.gmail.com>
	<31BC6DFF-905F-4B2B-8676-A06731BFD475@mac.com>
	<20110409192933.GA1644@polanet.pl>
	<079E859F-6FA0-4060-B9F1-5D94E5BC9E0B@mac.com>
	<20110409195018.GB1644@polanet.pl>
	<069BCEEF-7737-44D3-8808-58AB33F6295F@mac.com>
	<20110409201612.GA6403@polanet.pl>
	<234FE8AB-9FB5-433E-B6B5-4ADCBF2FAB9B@mac.com>
	<20110409205254.GB6403@polanet.pl>
Message-ID: <12FE8C25-0DC4-42D1-9C53-66B0EB4AA219@mac.com>


On Apr 9, 2011, at 4:52 PM, Tomasz Pala wrote:

> On Sat, Apr 09, 2011 at 16:32:01 -0400, Jeff Johnson wrote:
> 
>>> And I've shown that this "way" is wrong - having xattrs outside package
>>> manager is bad design per se.
>> 
>> You WILL have users using python eggs, and there WILL be a window
>> installing content outside of package management.
> 
> And how is this related to storing xattrs?

Its related to SELinux security labeling. To
ensure consistency, a label MUST be attached everywhere.

This was initially done by RPM. But "package management" does
not include home directories and other places where "windows"
lurk.

> 
> [...]
>> None of the above involves rpm "package management" installing xattr's.
> 
> Exactly - so don't throw me with arguments I do not care at all. I say
> rpm should handle xattrs, nothing more.
> 

And I'm not disagreeing. How rpm should handle xattr's like
that capabilities you want is a whole different matter.

Attaching Yet Another per-file tag everywhere just to set
a capaibility for, say, ping and perhaps 100-300 other
files (there's often > 1M, try "rpm -qal | wc -l")
is a fairly expensive undertaking.

And its quite silly to have _EVERY_ file have an attached (and
usually empty/missing) capability when the right approach
is to run a short list of paths that *do* need a capability attached.

(the above is wrto what is implemented @rpm.org)

>> And none of the above precludes rpm from attaching xattr's where it makes sense.
>> This thread started -- not about secuirity -- but how to handle
>> *.pyo side effects.
> 
> I have no idea and I really do not care a bit. What I do know is that
> application level is less important than system level, and the latter
> requires xattrs in modern package management system.
> How do we use them THEN, it's another issue.
> 

Well if you don't care abt *.pyo side effects, you're in the wrong thread.

>> SO get rid of SUID.
> 
> I can't - rpm doesn't support xattrs (or it's so top secret you can't
> tell me how to do this).
> 

Bullshit: rpm.org supports capabilities, and I just outlined what @rpm5.org
is going to do. What PLD does with RPM is entirely up to PLD, rpm-4.5 has
no upgrade path, discussed at length repeatedly with both arekm and glenn.

>> What SUID has to do with "package management" of
>> *.pyo side-effects isn't clear.
> 
> Did I mention some pyo somewhere?
> 

You're in the wrong thread. It really doesn't matter what you mentioned.

>>> So how can I store these caps in rpm? Or force rpm not to overwrite
>>> these set by me in filesystem (manually or by other tool)?
>> 
>> How does rpm store data in an rpmdb? You look at the schema,
>> you create records conistent with the schema, and you write
>> tools to make that happen for other data.
> 
> Thanks, that really helps. You could just write 'create your own package
> manager'.
> 

What do you think python eggs and ruby gems are if not "packages"?

>> Reasoning from "RPM has a database" -> "All content MUST be delivered
>> in *.rpm packages" -> "I want to remove SUID's!" is rather muddled.
> 
> No. "RPM delivers content with SUIDs instead of ACLs/caps" -> "RPM
> should be fixed to handle xattrs".
> 

At this point, all I can say is
	Patches cheerfully accepted.
I personally can't justify adding Yet Another per-file tag, but
if that's what you want, I can/will add *exactly* what is at
rpm.org under a vendor-peculier #ifdef.

>> And this thread started (see Subject:) with
>> 
>> 	What should be done with python's Newer! Better! Bestest!
>> 	convention for storing compiled *.pyo files?
>> 
>> not anything else.
> 
> It started like this, I've added something else. That is how discussions
> work, subject doesn't have to be fixed as nobody has to stick the first mail
> only.
> 

What do you think about radiation leakage in JA? Does that concern you or not?

I kinda prefer Hillary over Obama: chicks in charge! Are there any females in
positions of power in Poland? I just heard about MAM in France, she's cool!

Yep, its all discussion, isn't it?


>> And all I wished to point out is the (rather flawed imho) reasoning
>> that led to putting *.pyo files into *.rpm packages so that
>> SELinux trolls could pretend to a solution based on security tags
>> instantiated in xattr's.
> 
> Maybe, don't know, don't care, won't argue.
> 

I've tried repeatedly to avoid argument:
	Patches cheerfully accepted.
if you want to remove SUID's and use capabilities instead.

hth

73 de Jeff
> -- 
> Tomasz Pala <gotar at pld-linux.org>
> _______________________________________________
> pld-devel-en mailing list
> pld-devel-en at lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4645 bytes
Desc: not available
URL: </mailman/pipermail/pld-devel-en/attachments/20110409/327b6177/attachment.p7s>

From gotar at polanet.pl  Sun Apr 10 00:49:16 2011
From: gotar at polanet.pl (Tomasz Pala)
Date: Sun, 10 Apr 2011 00:49:16 +0200
Subject: python3.2+ compiled files
In-Reply-To: <12FE8C25-0DC4-42D1-9C53-66B0EB4AA219@mac.com>
References: <BANLkTinDoT5eB=4q0U07i8+Szkvh0Sqe=A@mail.gmail.com>
	<31BC6DFF-905F-4B2B-8676-A06731BFD475@mac.com>
	<20110409192933.GA1644@polanet.pl>
	<079E859F-6FA0-4060-B9F1-5D94E5BC9E0B@mac.com>
	<20110409195018.GB1644@polanet.pl>
	<069BCEEF-7737-44D3-8808-58AB33F6295F@mac.com>
	<20110409201612.GA6403@polanet.pl>
	<234FE8AB-9FB5-433E-B6B5-4ADCBF2FAB9B@mac.com>
	<20110409205254.GB6403@polanet.pl>
	<12FE8C25-0DC4-42D1-9C53-66B0EB4AA219@mac.com>
Message-ID: <20110409224916.GA11805@polanet.pl>

On Sat, Apr 09, 2011 at 17:09:54 -0400, Jeff Johnson wrote:

> And I'm not disagreeing. How rpm should handle xattr's like
> that capabilities you want is a whole different matter.
> 
> Attaching Yet Another per-file tag everywhere just to set
> a capaibility for, say, ping and perhaps 100-300 other
> files (there's often > 1M, try "rpm -qal | wc -l")
> is a fairly expensive undertaking.
> 
> And its quite silly to have _EVERY_ file have an attached (and
> usually empty/missing) capability when the right approach
> is to run a short list of paths that *do* need a capability attached.

Still, this is an implementation detail I won't meddle. The other time
you've mentioned that this could be accomplished by %post(un) and
%verify, so as far as I'm concerned %files section could have %acl or
%caps tags which would be converted to appropriate functions during spec
parse or something, you might be right that it doesn't make much sense to
attach them to every single file.

> (the above is wrto what is implemented @rpm.org)
[...]
>> I can't - rpm doesn't support xattrs (or it's so top secret you can't
>> tell me how to do this).
> 
> Bullshit: rpm.org supports capabilities,

And %caps() only - without ACLs, we could have use for, e.g.
default:group:logs:r on /var/log as currently some logs are NOT readable
by user in logs group and this is beyond caps scope (DAC_OVERRIDE would
be per entire user x app set).

> I personally can't justify adding Yet Another per-file tag, but
> if that's what you want, I can/will add *exactly* what is at
> rpm.org under a vendor-peculier #ifdef.

What exactly is the overhead of empty tag?

> What do you think about radiation leakage in JA? Does that concern you or not?

It doesn't.

> I kinda prefer Hillary over Obama: chicks in charge! Are there any females in
> positions of power in Poland? I just heard about MAM in France, she's cool!

Sorry, don't care either.

> I've tried repeatedly to avoid argument:
> 	Patches cheerfully accepted.
> if you want to remove SUID's and use capabilities instead.

There are patches - in rpm.org as you know.

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


From n3npq at mac.com  Sun Apr 10 01:05:33 2011
From: n3npq at mac.com (Jeff Johnson)
Date: Sat, 09 Apr 2011 19:05:33 -0400
Subject: python3.2+ compiled files
In-Reply-To: <20110409224916.GA11805@polanet.pl>
References: <BANLkTinDoT5eB=4q0U07i8+Szkvh0Sqe=A@mail.gmail.com>
	<31BC6DFF-905F-4B2B-8676-A06731BFD475@mac.com>
	<20110409192933.GA1644@polanet.pl>
	<079E859F-6FA0-4060-B9F1-5D94E5BC9E0B@mac.com>
	<20110409195018.GB1644@polanet.pl>
	<069BCEEF-7737-44D3-8808-58AB33F6295F@mac.com>
	<20110409201612.GA6403@polanet.pl>
	<234FE8AB-9FB5-433E-B6B5-4ADCBF2FAB9B@mac.com>
	<20110409205254.GB6403@polanet.pl>
	<12FE8C25-0DC4-42D1-9C53-66B0EB4AA219@mac.com>
	<20110409224916.GA11805@polanet.pl>
Message-ID: <15888A14-6477-46EC-9F1B-84A5C6FAFFBF@mac.com>


On Apr 9, 2011, at 6:49 PM, Tomasz Pala wrote:

> On Sat, Apr 09, 2011 at 17:09:54 -0400, Jeff Johnson wrote:
> 
>> And I'm not disagreeing. How rpm should handle xattr's like
>> that capabilities you want is a whole different matter.
>> 
>> Attaching Yet Another per-file tag everywhere just to set
>> a capaibility for, say, ping and perhaps 100-300 other
>> files (there's often > 1M, try "rpm -qal | wc -l")
>> is a fairly expensive undertaking.
>> 
>> And its quite silly to have _EVERY_ file have an attached (and
>> usually empty/missing) capability when the right approach
>> is to run a short list of paths that *do* need a capability attached.
> 
> Still, this is an implementation detail I won't meddle. The other time
> you've mentioned that this could be accomplished by %post(un) and
> %verify, so as far as I'm concerned %files section could have %acl or
> %caps tags which would be converted to appropriate functions during spec
> parse or something, you might be right that it doesn't make much sense to
> attach them to every single file.
> 
>> (the above is wrto what is implemented @rpm.org)
> [...]
>>> I can't - rpm doesn't support xattrs (or it's so top secret you can't
>>> tell me how to do this).
>> 
>> Bullshit: rpm.org supports capabilities,
> 
> And %caps() only - without ACLs, we could have use for, e.g.
> default:group:logs:r on /var/log as currently some logs are NOT readable
> by user in logs group and this is beyond caps scope (DAC_OVERRIDE would
> be per entire user x app set).
> 
>> I personally can't justify adding Yet Another per-file tag, but
>> if that's what you want, I can/will add *exactly* what is at
>> rpm.org under a vendor-peculier #ifdef.
> 
> What exactly is the overhead of empty tag?

FOr a distro containing >1M files, empty string tags require (at least) '\0'.

But ~1Mb (for a 1M file distro) additional info is moderately significant. Go look at
	ls -al /var/lib/rpm/Packages
run
	rpm -qal | wc -l
and then add that number of bytes for an empty tag. Then also
add that to download times, and space on RO media.

Already all strings are saved in rpmdb indices without trailing '\0'
in order to save several megabytes of space.

> 
>> What do you think about radiation leakage in JA? Does that concern you or not?
> 
> It doesn't.
> 
>> I kinda prefer Hillary over Obama: chicks in charge! Are there any females in
>> positions of power in Poland? I just heard about MAM in France, she's cool!
> 
> Sorry, don't care either.
> 
>> I've tried repeatedly to avoid argument:
>> 	Patches cheerfully accepted.
>> if you want to remove SUID's and use capabilities instead.
> 
> There are patches - in rpm.org as you know.
> 

I'm well aware of what is @rpm.org even if you are not. You claimed
that rpm was preventing you from remoing SUID.

I'm also aware that Fedora tried removing SUID, and has packaged
with capabilities. *shrug*

There's lots of ways to run a command against 100-300 files to
add capabilities "securely", without raciness, and without
getting "package management" involved. SInce you are adding a capabity,
it just means that the file will be installed in unprivlieged
capabilty-free mode until the capability is added, just like SUID's.

And ultimately, neither @rpm5.org or @rpm.org code is in use by PLD,
so it matters about as muct as radiation damage and chicks in charge
discussions.

73 de Jeff
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4645 bytes
Desc: not available
URL: </mailman/pipermail/pld-devel-en/attachments/20110409/471006a8/attachment.p7s>

From gotar at polanet.pl  Sun Apr 10 01:38:55 2011
From: gotar at polanet.pl (Tomasz Pala)
Date: Sun, 10 Apr 2011 01:38:55 +0200
Subject: python3.2+ compiled files
In-Reply-To: <15888A14-6477-46EC-9F1B-84A5C6FAFFBF@mac.com>
References: <20110409192933.GA1644@polanet.pl>
	<079E859F-6FA0-4060-B9F1-5D94E5BC9E0B@mac.com>
	<20110409195018.GB1644@polanet.pl>
	<069BCEEF-7737-44D3-8808-58AB33F6295F@mac.com>
	<20110409201612.GA6403@polanet.pl>
	<234FE8AB-9FB5-433E-B6B5-4ADCBF2FAB9B@mac.com>
	<20110409205254.GB6403@polanet.pl>
	<12FE8C25-0DC4-42D1-9C53-66B0EB4AA219@mac.com>
	<20110409224916.GA11805@polanet.pl>
	<15888A14-6477-46EC-9F1B-84A5C6FAFFBF@mac.com>
Message-ID: <20110409233855.GA17209@polanet.pl>

On Sat, Apr 09, 2011 at 19:05:33 -0400, Jeff Johnson wrote:

> FOr a distro containing >1M files, empty string tags require (at least) '\0'.
> 
> But ~1Mb (for a 1M file distro) additional info is moderately significant. Go look at
> 	ls -al /var/lib/rpm/Packages
> run
> 	rpm -qal | wc -l
> and then add that number of bytes for an empty tag.

It's 0.3% in my case.

> Then also add that to download times,

You must be kidding - downloading 1 MB more considering entire distro is
nothing.

> and space on RO media.
>
> Already all strings are saved in rpmdb indices without trailing '\0'
> in order to save several megabytes of space.

Looking for a real savings?

~:  grep install_langs /etc/rpm/*
/etc/rpm/macros:%_install_langs pl_PL
~:  LANG=pt_BR rpm -qi alsa-lib
Bibliotecas para o ALSA. Esse pacote ? necess?rio para rodar programas
Linux queusam o driver de som ALSA.

It would be sufficient to have some rpmdb postprocessing tools to remove
descriptions or changelogs from database, especially for RO medias where
no rollbacks would ever be required.

>> There are patches - in rpm.org as you know.
> 
> I'm well aware of what is @rpm.org even if you are not.

Maybe I'm not - how does it even matter?

> You claimed that rpm was preventing you from remoing SUID.

Yeah - %caps() was added in 4.6 and we got 4.5 here in PLD.

> I'm also aware that Fedora tried removing SUID, and has packaged
> with capabilities. *shrug*

Are you aware that SUID (and superuser at all) could be disabled on
destination host? Thus it's not required to actually remove this bit in
package, The Point is to supply proper xattrs and leave user a choice.

> There's lots of ways to run a command against 100-300 files to
> add capabilities "securely", without raciness, and without
> getting "package management" involved.

Assuming this "way" can undo transaction (full rollback) in context of
privilidged process. How to setcap setcap binary after upgrade?

> SInce you are adding a capabity,
> it just means that the file will be installed in unprivlieged
> capabilty-free mode until the capability is added, just like SUID's.

Unless one wokes up with no privilidged apps in system.

> And ultimately, neither @rpm5.org or @rpm.org code is in use by PLD,
> so it matters about as muct as radiation damage and chicks in charge
> discussions.

Eventually one of these will be used, but I doubt PLD is used in nuclear
installations or by chicks in charge.

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


From n3npq at mac.com  Sun Apr 10 01:52:34 2011
From: n3npq at mac.com (Jeff Johnson)
Date: Sat, 09 Apr 2011 19:52:34 -0400
Subject: python3.2+ compiled files
In-Reply-To: <20110409233855.GA17209@polanet.pl>
References: <20110409192933.GA1644@polanet.pl>
	<079E859F-6FA0-4060-B9F1-5D94E5BC9E0B@mac.com>
	<20110409195018.GB1644@polanet.pl>
	<069BCEEF-7737-44D3-8808-58AB33F6295F@mac.com>
	<20110409201612.GA6403@polanet.pl>
	<234FE8AB-9FB5-433E-B6B5-4ADCBF2FAB9B@mac.com>
	<20110409205254.GB6403@polanet.pl>
	<12FE8C25-0DC4-42D1-9C53-66B0EB4AA219@mac.com>
	<20110409224916.GA11805@polanet.pl>
	<15888A14-6477-46EC-9F1B-84A5C6FAFFBF@mac.com>
	<20110409233855.GA17209@polanet.pl>
Message-ID: <BF8360E0-90B7-4A03-A35B-1C456B501B30@mac.com>


On Apr 9, 2011, at 7:38 PM, Tomasz Pala wrote:

> On Sat, Apr 09, 2011 at 19:05:33 -0400, Jeff Johnson wrote:
> 
>> FOr a distro containing >1M files, empty string tags require (at least) '\0'.
>> 
>> But ~1Mb (for a 1M file distro) additional info is moderately significant. Go look at
>> 	ls -al /var/lib/rpm/Packages
>> run
>> 	rpm -qal | wc -l
>> and then add that number of bytes for an empty tag.
> 
> It's 0.3% in my case.
> 

SO add the tag. I can't justify the implementation for lots of reasons,
not only space. I answered what the overhead cost was, not what the
complexity cost is/was.


>> Then also add that to download times,
> 
> You must be kidding - downloading 1 MB more considering entire distro is
> nothing.
> 

I son't personally think download is worth worrying about.
Meanwhile -- for lots of reasons -- other do,
and blame RPM for "bloat".

>> and space on RO media.
>> 
>> Already all strings are saved in rpmdb indices without trailing '\0'
>> in order to save several megabytes of space.
> 
> Looking for a real savings?
> 
> ~:  grep install_langs /etc/rpm/*
> /etc/rpm/macros:%_install_langs pl_PL
> ~:  LANG=pt_BR rpm -qi alsa-lib
> Bibliotecas para o ALSA. Esse pacote ? necess?rio para rodar programas
> Linux queusam o driver de som ALSA.
> 
> It would be sufficient to have some rpmdb postprocessing tools to remove
> descriptions or changelogs from database, especially for RO medias where
> no rollbacks would ever be required.
> 

I'm well aware of the cost of RPM_I18NSTRING_TYPE. There are 2 distros
left using %description -l XY in *.spec recipes.

Mandriva is the other distro ... all @redhat derived distros stopped
using locales in *.spec a decade ago.

>>> There are patches - in rpm.org as you know.
>> 
>> I'm well aware of what is @rpm.org even if you are not.
> 
> Maybe I'm not - how does it even matter?
> 

It doesn't matter -- we;re having a dscussion abt *.pyo files in python 3.2, aren't we?

>> You claimed that rpm was preventing you from remoing SUID.
> 
> Yeah - %caps() was added in 4.6 and we got 4.5 here in PLD.
> 

You're foolish if you think 4.6 > 4.5 and hence "newer".

>> I'm also aware that Fedora tried removing SUID, and has packaged
>> with capabilities. *shrug*
> 
> Are you aware that SUID (and superuser at all) could be disabled on
> destination host? Thus it's not required to actually remove this bit in
> package, The Point is to supply proper xattrs and leave user a choice.
> 

SO remobve SUID's or disable SUID's or write the script that attaches
capabilities to 100-300 files (a generous over estimate considering
how few setuid programs ther actually are), and do whatever you please.

But it simply isn't true that RPM "package mangement" is stopping you
from implementing SUID removal or me from discussing chicks-in-charge.

A chick would be busily scrubbing out SUID's already ...

>> There's lots of ways to run a command against 100-300 files to
>> add capabilities "securely", without raciness, and without
>> getting "package management" involved.
> 
> Assuming this "way" can undo transaction (full rollback) in context of
> privilidged process. How to setcap setcap binary after upgrade?
> 

Re-run the script and write it with +capability/-capability and --rollback if you ish.

>> SInce you are adding a capabity,
>> it just means that the file will be installed in unprivlieged
>> capabilty-free mode until the capability is added, just like SUID's.
> 
> Unless one wokes up with no privilidged apps in system.
> 

Too bad for you.

>> And ultimately, neither @rpm5.org or @rpm.org code is in use by PLD,
>> so it matters about as muct as radiation damage and chicks in charge
>> discussions.
> 
> Eventually one of these will be used, but I doubt PLD is used in nuclear
> installations or by chicks in charge.
> 

Wanna bet? AFAIK, PLD is happier with its own fork of RPM. I have offered
to assist with upgrade multiple times, gave up caring a few years back
because what PLD does is up to PLD.

But yes, there's a horrendous amount of "bloat" associated with
	%description -l XY

WHich is why RPM_I18NSTRING_TYPE was abandoned (as in not used, yes the
implementation still exists, as b0rken as ever, in RPM) a decade ago.

But "Not yet." for PLD and Mandriva.

73 de Jeff
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4645 bytes
Desc: not available
URL: </mailman/pipermail/pld-devel-en/attachments/20110409/1813c25c/attachment.p7s>

From gotar at polanet.pl  Sun Apr 10 02:36:15 2011
From: gotar at polanet.pl (Tomasz Pala)
Date: Sun, 10 Apr 2011 02:36:15 +0200
Subject: RPM vs xattrs [was: python3.2+ compiled files]
In-Reply-To: <BF8360E0-90B7-4A03-A35B-1C456B501B30@mac.com>
References: <20110409195018.GB1644@polanet.pl>
	<069BCEEF-7737-44D3-8808-58AB33F6295F@mac.com>
	<20110409201612.GA6403@polanet.pl>
	<234FE8AB-9FB5-433E-B6B5-4ADCBF2FAB9B@mac.com>
	<20110409205254.GB6403@polanet.pl>
	<12FE8C25-0DC4-42D1-9C53-66B0EB4AA219@mac.com>
	<20110409224916.GA11805@polanet.pl>
	<15888A14-6477-46EC-9F1B-84A5C6FAFFBF@mac.com>
	<20110409233855.GA17209@polanet.pl>
	<BF8360E0-90B7-4A03-A35B-1C456B501B30@mac.com>
Message-ID: <20110410003615.GB17209@polanet.pl>

On Sat, Apr 09, 2011 at 19:52:34 -0400, Jeff Johnson wrote:

> SO add the tag. I can't justify the implementation for lots of reasons,
> not only space. I answered what the overhead cost was, not what the
> complexity cost is/was.

Once again you write about 'some reasons' and keep them for yourself, I
don't know if you are assuming we're too dumb to understand them, but I
see that they got no problems with capabilities at rpm.org, so - well,
maybe it just works?

>>> Then also add that to download times,
>> 
>> You must be kidding - downloading 1 MB more considering entire distro is
>> nothing.
> 
> I son't personally think download is worth worrying about.

So why do you mention this, to keep me busy answering such bullshit?

> Meanwhile -- for lots of reasons -- other do,
> and blame RPM for "bloat".

Well, if the reasons are lots in numbers, than OK. But why didn't you
put any here, just the less important ones?

> I'm well aware of the cost of RPM_I18NSTRING_TYPE. There are 2 distros
> left using %description -l XY in *.spec recipes.
> 
> Mandriva is the other distro ... all @redhat derived distros stopped
> using locales in *.spec a decade ago.

Did they removed translations entirely or put them in some better place?
BTW it's you who wrote we've got good engineering practices often.

>>>> There are patches - in rpm.org as you know.
>>> 
>>> I'm well aware of what is @rpm.org even if you are not.
>> 
>> Maybe I'm not - how does it even matter?
> 
> It doesn't matter -- we;re having a dscussion abt *.pyo files in python 3.2, aren't we?

Especially for you, with dedication, I've changed subject of this
thread. Can we now focus on technical discussion not form and style?

>>> You claimed that rpm was preventing you from remoing SUID.
>> 
>> Yeah - %caps() was added in 4.6 and we got 4.5 here in PLD.
> 
> You're foolish if you think 4.6 > 4.5 and hence "newer".

You're foolish if you think I'm not aware of distinct lines of rpm.
You exactly know that there's no 4.5 at rpm.org and no 4.6 at rpm5.org,
so adding adjuncts would be robust.

>> package, The Point is to supply proper xattrs and leave user a choice.
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> SO remobve SUID's or disable SUID's or write the script that attaches
> capabilities to 100-300 files (a generous over estimate considering
> how few setuid programs ther actually are), and do whatever you please.

Sure, I can write a script to maintain database of untared archives.
Wait a minute, isn't it a package manager?

> But it simply isn't true that RPM "package mangement" is stopping you
> from implementing SUID removal or me from discussing chicks-in-charge.

RPM prevents me from having non-destructable upon regular system
maintaince xattrs, which are required for SUID/UID==0 removal.

>> Assuming this "way" can undo transaction (full rollback) in context of
>> privilidged process. How to setcap setcap binary after upgrade?
> 
> Re-run the script and write it with +capability/-capability and --rollback if you ish.

I can't re-run it, because at this moment it is already unpriviledged.
You know what, just chmod -x /bin/* and have fun.

>> Unless one wokes up with no privilidged apps in system.
> 
> Too bad for you.

That's all you can say?

>> Eventually one of these will be used, but I doubt PLD is used in nuclear
>> installations or by chicks in charge.
> 
> Wanna bet? AFAIK, PLD is happier with its own fork of RPM.

I don't know who is happier, I don't know all the differences, I see
different branches in CVS _including_ rpm5.org and rpm.org.

> I have offered
> to assist with upgrade multiple times, gave up caring a few years back
> because what PLD does is up to PLD.

If you've offered this in a way you 'offer' to support caps (go write a
script or send me patch) you shouldn't be surprised...

> But yes, there's a horrendous amount of "bloat" associated with
> 	%description -l XY
> 
> WHich is why RPM_I18NSTRING_TYPE was abandoned (as in not used, yes the
> implementation still exists, as b0rken as ever, in RPM) a decade ago.
> 
> But "Not yet." for PLD and Mandriva.

~:  rpm -qai | wc -c
1648049

in C locale, my entire /var/lib/rpm uses 70 MB and I don't care. But
saving '\0'? Seriously?

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


From n3npq at mac.com  Sun Apr 10 02:41:47 2011
From: n3npq at mac.com (Jeff Johnson)
Date: Sat, 09 Apr 2011 20:41:47 -0400
Subject: RPM vs xattrs [was: python3.2+ compiled files]
In-Reply-To: <20110410003615.GB17209@polanet.pl>
References: <20110409195018.GB1644@polanet.pl>
	<069BCEEF-7737-44D3-8808-58AB33F6295F@mac.com>
	<20110409201612.GA6403@polanet.pl>
	<234FE8AB-9FB5-433E-B6B5-4ADCBF2FAB9B@mac.com>
	<20110409205254.GB6403@polanet.pl>
	<12FE8C25-0DC4-42D1-9C53-66B0EB4AA219@mac.com>
	<20110409224916.GA11805@polanet.pl>
	<15888A14-6477-46EC-9F1B-84A5C6FAFFBF@mac.com>
	<20110409233855.GA17209@polanet.pl>
	<BF8360E0-90B7-4A03-A35B-1C456B501B30@mac.com>
	<20110410003615.GB17209@polanet.pl>
Message-ID: <2AD947E5-D754-466D-9B08-D95CEC9DAFF7@mac.com>


On Apr 9, 2011, at 8:36 PM, Tomasz Pala wrote:

> BTW it's you who wrote we've got good engineering practices often.
> 

Let's just leave it here:

	PLD is my favorite distro, solves problems (like *.pyo files
	changing in python 3.2+), devises fixes, and moves on
	months and years before other distros even begin to say
		Huh?

Now if PLD had a chick-in-charge, well, the engineering would be better yet.

73 de Jeff
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4645 bytes
Desc: not available
URL: </mailman/pipermail/pld-devel-en/attachments/20110409/ac893dc7/attachment.p7s>

From qboosh at pld-linux.org  Sun Apr 10 11:17:13 2011
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Sun, 10 Apr 2011 11:17:13 +0200
Subject: python3.2+ compiled files
In-Reply-To: <20110409190344.GA2636@home.lan>
References: <20110402181118.GA22787@stranger.qboosh.pl>
	<4DA051B3.6090705@pld-linux.org> <20110409190344.GA2636@home.lan>
Message-ID: <20110410091713.GA19786@mail>

On Sat, Apr 09, 2011 at 09:03:44PM +0200, Jan R?korajski wrote:
> On Sat, 09 Apr 2011, Elan Ruusam?e wrote:
> 
> > as for the .py sources packaging, i'd move them to -debuginfo package so 
> > the could be installed optionally
> 
> Are you aware that some python apps do runtime feature checking and
> setting based od the presence of .py files? That those apps can't live
> without them? python-numpy being an example.

Actually this one is a weak argument - detecting python modules by searching
some hardcoded (or, even worse, scanned throughout /usr/*/python*) file
paths instead of import availability is rather a hack.

BTW: has anybody looked how other distros handle python 3.2 (both core
distribution and external modules)?


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


From wrobell at pld-linux.org  Sun Apr 10 12:02:26 2011
From: wrobell at pld-linux.org (Artur Wroblewski)
Date: Sun, 10 Apr 2011 11:02:26 +0100
Subject: python3.2+ compiled files
In-Reply-To: <20110410091713.GA19786@mail>
References: <20110402181118.GA22787@stranger.qboosh.pl>
	<4DA051B3.6090705@pld-linux.org> <20110409190344.GA2636@home.lan>
	<20110410091713.GA19786@mail>
Message-ID: <BANLkTimGdicdPRy1cLEwdeWh3srwdqo4tQ@mail.gmail.com>

2011/4/10 Jakub Bogusz <qboosh at pld-linux.org>:
> On Sat, Apr 09, 2011 at 09:03:44PM +0200, Jan R?korajski wrote:
>> On Sat, 09 Apr 2011, Elan Ruusam?e wrote:
>>
>> > as for the .py sources packaging, i'd move them to -debuginfo package so
>> > the could be installed optionally
>>
>> Are you aware that some python apps do runtime feature checking and
>> setting based od the presence of .py files? That those apps can't live
>> without them? python-numpy being an example.
>
> Actually this one is a weak argument - detecting python modules by searching
> some hardcoded (or, even worse, scanned throughout /usr/*/python*) file
> paths instead of import availability is rather a hack.

Indeed, modules searching caused us problems in few cases, but patches
were always accepted by the authors of the offending software.

While speaking about rules, IMHO, we can treat such problems in exactly
the same way as autoconf/automake problems - we patch "configure.{in,ac}"
and "Makefile.am" not "configure" and "Makefile" files. More work for us in
first place, but better outcome in longer term for everyone.

Best regards,

w


From qboosh at pld-linux.org  Sun Apr 10 12:57:51 2011
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Sun, 10 Apr 2011 12:57:51 +0200
Subject: geninitrd: mod-suspend broken with dynamic dev nodes
Message-ID: <20110410105751.GA20240@mail>

I've been hit by USE_SUSPEND being incompatible with any features that
need dev nodes created online (including USE_BLKID, which is on by
default and not even mentioned in /etc/sysconfig/geninitrd) and no udev.

The problem is that mod-suspend makes dev nodes (/dev/snapshot and
resume device) only when creating initial initrd fs, but in linuxrc
dynamic nodes support overrides /dev by mounting tmpfs there - so
required nodes disappear and resume fails.

Disabling all LVMs and BLKID fixes resume.


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


From arekm at maven.pl  Sun Apr 10 13:07:00 2011
From: arekm at maven.pl (Arkadiusz Miskiewicz)
Date: Sun, 10 Apr 2011 13:07:00 +0200
Subject: geninitrd: mod-suspend broken with dynamic dev nodes
In-Reply-To: <20110410105751.GA20240@mail>
References: <20110410105751.GA20240@mail>
Message-ID: <201104101307.01002.arekm@maven.pl>

On Sunday 10 of April 2011, Jakub Bogusz wrote:

> The problem is that mod-suspend makes dev nodes (/dev/snapshot and
> resume device) only when creating initial initrd fs, but in linuxrc
> dynamic nodes support overrides /dev by mounting tmpfs there - so
> required nodes disappear and resume fails.

Isn't your resume device created runtime with data from /proc/partitions?

> Disabling all LVMs and BLKID fixes resume.

I hope that creating /dev/snapshot in tmpfs will be enough (commited).

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


From glen at pld-linux.org  Mon Apr 11 12:31:44 2011
From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Mon, 11 Apr 2011 13:31:44 +0300
Subject: python3.2+ compiled files
In-Reply-To: <20110409190344.GA2636@home.lan>
References: <20110402181118.GA22787@stranger.qboosh.pl>	<4DA051B3.6090705@pld-linux.org>
	<20110409190344.GA2636@home.lan>
Message-ID: <4DA2D890.50102@pld-linux.org>

On 09.04.2011 22:03, Jan R?korajski wrote:
> On Sat, 09 Apr 2011, Elan Ruusam?e wrote:
>
>> as for the .py sources packaging, i'd move them to -debuginfo package so
>> the could be installed optionally
> Are you aware that some python apps do runtime feature checking and
> setting based od the presence of .py files? That those apps can't live
> without them? python-numpy being an example.


and there we should proceed as we have done now --

patch the code not to use hardcoded .py for searching,
which usually ends up patching for searching hardcoded .pyc :)

ps: i saw your change, had plan to look at it later

-- 
glen



From udvzsolt at gmail.com  Tue Apr 12 15:58:56 2011
From: udvzsolt at gmail.com (Zsolt Udvari)
Date: Tue, 12 Apr 2011 15:58:56 +0200
Subject: CodeIgniter
Message-ID: <BANLkTimN0oSGsowMM6KiF4jQxkV9pSgPpw@mail.gmail.com>

Hello all!

I've added a php framework (development) to packages, named CodeIgniter.
It is not perfect (what is perfect?:)), so I've a question, I hope,
anybody will have any idea.
So. I redirect /usr/share/CodeIgniter to /ci (like phpMyAdmin).
In /ci/index.php there are some config settings.
See $application_folder. It says to CI, where should search the applications.

In my home-directory has a CI, in ~/public_html, its index.php:
$application_folder = "/home/users/zsolt/progs/codeigniter/application";

So when I type localhost/~zsolt/index.php/FOO, CI will search its
components in ~/progs/codeigniter/application/{controllers,models,views}
directory.
It's OK. But as I see, CI doesn't handle plus directories in URI (in
browser), so when application_folder is
/home/users/zsolt/progs/codeigniter, the
localhost/~zsolt/index.php/application/FOO doesn't work.

So, I want to know is there any workaround to avoid this problem?
What I wanted it? The application_folder is /home/users, so maybe I
can access my CI programs via localhost/ci/index.php/zsolt/.....
Maybe another way or similar. Any suggestion?

Zsolt


From gotar at polanet.pl  Tue Apr 12 22:39:10 2011
From: gotar at polanet.pl (Tomasz Pala)
Date: Tue, 12 Apr 2011 22:39:10 +0200
Subject: CodeIgniter
In-Reply-To: <BANLkTimN0oSGsowMM6KiF4jQxkV9pSgPpw@mail.gmail.com>
References: <BANLkTimN0oSGsowMM6KiF4jQxkV9pSgPpw@mail.gmail.com>
Message-ID: <20110412203910.GA3151@polanet.pl>

On Tue, Apr 12, 2011 at 15:58:56 +0200, Zsolt Udvari wrote:

> I've added a php framework (development) to packages, named CodeIgniter.
> It is not perfect (what is perfect?:)), so I've a question, I hope,
> anybody will have any idea.
> So. I redirect /usr/share/CodeIgniter to /ci (like phpMyAdmin).

If it is a framework it must be totally broken if requires it's files in
web-accessible tree (I mean engine, not some icons or other media).

> In /ci/index.php there are some config settings.
> See $application_folder. It says to CI, where should search the applications.

Wrong - how would you run multiple projects using this single location?
If it's not multiuser, there's no much sense in installing it via rpm.

You should have this index.php (packaged as template) in your
~/public_html and put into this file location of framework files.

> In my home-directory has a CI, in ~/public_html, its index.php:
> $application_folder = "/home/users/zsolt/progs/codeigniter/application";
> 
> So when I type localhost/~zsolt/index.php/FOO, CI will search its
> components in ~/progs/codeigniter/application/{controllers,models,views}
> directory.

It should in /usr/share/CodeIgniter, that's the point of packaging
stuff.

> What I wanted it? The application_folder is /home/users, so maybe I
> can access my CI programs via localhost/ci/index.php/zsolt/.....
> Maybe another way or similar. Any suggestion?

Don't know CI, but corner case of Symfony or Smarty is having _single_
PHP file (index.php) in web tree, it contains only configuration (like
db); all remaining files is static content (media, css, user js etc).

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


From udvzsolt at gmail.com  Wed Apr 13 09:50:56 2011
From: udvzsolt at gmail.com (Zsolt Udvari)
Date: Wed, 13 Apr 2011 09:50:56 +0200
Subject: CodeIgniter
In-Reply-To: <20110412203910.GA3151@polanet.pl>
References: <BANLkTimN0oSGsowMM6KiF4jQxkV9pSgPpw@mail.gmail.com>
	<20110412203910.GA3151@polanet.pl>
Message-ID: <BANLkTik7Kz+94oiY49NjOJDDzbP2etK=nQ@mail.gmail.com>

Please check the latest update (rev 1.2)! Do you think, it's okay? For
me it works.

2011/4/12 Tomasz Pala <gotar at polanet.pl>:
> On Tue, Apr 12, 2011 at 15:58:56 +0200, Zsolt Udvari wrote:
>
>> I've added a php framework (development) to packages, named CodeIgniter.
>> It is not perfect (what is perfect?:)), so I've a question, I hope,
>> anybody will have any idea.
>> So. I redirect /usr/share/CodeIgniter to /ci (like phpMyAdmin).
>
> If it is a framework it must be totally broken if requires it's files in
> web-accessible tree (I mean engine, not some icons or other media).
>
>> In /ci/index.php there are some config settings.
>> See $application_folder. It says to CI, where should search the applications.
>
> Wrong - how would you run multiple projects using this single location?
> If it's not multiuser, there's no much sense in installing it via rpm.
>
> You should have this index.php (packaged as template) in your
> ~/public_html and put into this file location of framework files.
>
>> In my home-directory has a CI, in ~/public_html, its index.php:
>> $application_folder = "/home/users/zsolt/progs/codeigniter/application";
>>
>> So when I type localhost/~zsolt/index.php/FOO, CI will search its
>> components in ~/progs/codeigniter/application/{controllers,models,views}
>> directory.
>
> It should in /usr/share/CodeIgniter, that's the point of packaging
> stuff.
>
>> What I wanted it? The application_folder is /home/users, so maybe I
>> can access my CI programs via localhost/ci/index.php/zsolt/.....
>> Maybe another way or similar. Any suggestion?
>
> Don't know CI, but corner case of Symfony or Smarty is having _single_
> PHP file (index.php) in web tree, it contains only configuration (like
> db); all remaining files is static content (media, css, user js etc).
>
> --
> Tomasz Pala <gotar at pld-linux.org>
> _______________________________________________
> pld-devel-en mailing list
> pld-devel-en at lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
>


From sls at poczta.wp.pl  Thu Apr 14 21:26:54 2011
From: sls at poczta.wp.pl (Szymon Siwek)
Date: Thu, 14 Apr 2011 21:26:54 +0200
Subject: packages: gedit2/gedit2.spec - updated to 3.0.0; merged from DEVEL
In-Reply-To: <packages_gedit2_gedit2.spec.1.148@pld-linux.org>
References: <packages_gedit2_gedit2.spec.1.147@pld-linux.org>
	<packages_gedit2_gedit2.spec.1.148@pld-linux.org>
Message-ID: <20110414192654.GA14825@cion.sls.kicks-ass.org>

On Tue, Apr 05, 2011 at 08:31:14PM +0200, megabajt wrote:
> Author: megabajt                     Date: Tue Apr  5 18:31:14 2011 GMT
> Module: packages                      Tag: HEAD
> ---- Log message:
> - updated to 3.0.0; merged from DEVEL
> 
> ---- Files affected:
> packages/gedit2:
>    gedit2.spec (1.147 -> 1.148) 
> 
It looks strange for me:

Name:		gedit2
Version:	3.0.0

-- 
Szymon Siwek


From marcin.rybak at gmail.com  Mon Apr 18 14:54:31 2011
From: marcin.rybak at gmail.com (Marcin Rybak)
Date: Mon, 18 Apr 2011 14:54:31 +0200
Subject: new package ossec-hids
Message-ID: <BANLkTimYBO9UsnkM_qCYVvjpXRZAkv4zGg@mail.gmail.com>

Hi,

I corrected and PLDized RHEL spec for OSsec-hids.
Cause it is my first spec, any help and comments is appreciated :)

some TODO:
#  - review patches
#  - review paths (to catch RHEL -> PLD differences)
#  - rewrite init script (this one is not working)
#  - review logrotate
#  - review permissions
#  - warning: Installed (but unpackaged) file(s) found:
#    /var/ossec/bin/ossec-makelists
#    /var/ossec/bin/ossec-regex

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


From qboosh at pld-linux.org  Tue Apr 19 06:48:50 2011
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Tue, 19 Apr 2011 06:48:50 +0200
Subject: new package ossec-hids
In-Reply-To: <BANLkTimYBO9UsnkM_qCYVvjpXRZAkv4zGg@mail.gmail.com>
References: <BANLkTimYBO9UsnkM_qCYVvjpXRZAkv4zGg@mail.gmail.com>
Message-ID: <20110419044850.GA20528@mail>

On Mon, Apr 18, 2011 at 02:54:31PM +0200, Marcin Rybak wrote:
> Hi,
> 
> I corrected and PLDized RHEL spec for OSsec-hids.
> Cause it is my first spec, any help and comments is appreciated :)

> #  - warning: Installed (but unpackaged) file(s) found:
> #    /var/ossec/bin/ossec-makelists
> #    /var/ossec/bin/ossec-regex

This path (/var/ossec) is not FHS compliant.
Variable package files should be placed in /var/lib/PACKAGE.
The above names suggest that the files are not even variable - so should
be in /usr/share/PACKAGE, /usr/lib*/PACKAGE (if they are arch-dependent)
or /usr/bin (if they are directly callable for user).


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


From marcin.rybak at gmail.com  Tue Apr 19 09:09:29 2011
From: marcin.rybak at gmail.com (Marcin Rybak)
Date: Tue, 19 Apr 2011 09:09:29 +0200
Subject: new package ossec-hids
In-Reply-To: <20110419044850.GA20528@mail>
References: <BANLkTimYBO9UsnkM_qCYVvjpXRZAkv4zGg@mail.gmail.com>
	<20110419044850.GA20528@mail>
Message-ID: <BANLkTimhcupGVVXQEKXLq4tkNb34rTYnsA@mail.gmail.com>

2011/4/19 Jakub Bogusz <qboosh at pld-linux.org>

> On Mon, Apr 18, 2011 at 02:54:31PM +0200, Marcin Rybak wrote:
> > Hi,
> >
> > I corrected and PLDized RHEL spec for OSsec-hids.
> > Cause it is my first spec, any help and comments is appreciated :)
>
> > #  - warning: Installed (but unpackaged) file(s) found:
> > #    /var/ossec/bin/ossec-makelists
> > #    /var/ossec/bin/ossec-regex
>
> This path (/var/ossec) is not FHS compliant.
> Variable package files should be placed in /var/lib/PACKAGE.
> The above names suggest that the files are not even variable - so should
> be in /usr/share/PACKAGE, /usr/lib*/PACKAGE (if they are arch-dependent)
> or /usr/bin (if they are directly callable for user).


you're right, I'll change it to correct ones.

Thanks,
---
Marcin Rybak
http://marcinrybak.com


From marcin.rybak at gmail.com  Tue Apr 19 22:41:11 2011
From: marcin.rybak at gmail.com (Marcin Rybak)
Date: Tue, 19 Apr 2011 22:41:11 +0200
Subject: new package ossec-hids
In-Reply-To: <BANLkTimhcupGVVXQEKXLq4tkNb34rTYnsA@mail.gmail.com>
References: <BANLkTimYBO9UsnkM_qCYVvjpXRZAkv4zGg@mail.gmail.com>
	<20110419044850.GA20528@mail>
	<BANLkTimhcupGVVXQEKXLq4tkNb34rTYnsA@mail.gmail.com>
Message-ID: <BANLkTikC0zwqt09PPW6cF4NyiF6pw2gcOA@mail.gmail.com>

2011/4/19 Marcin Rybak <marcin.rybak at gmail.com>

> 2011/4/19 Jakub Bogusz <qboosh at pld-linux.org>
>
>> On Mon, Apr 18, 2011 at 02:54:31PM +0200, Marcin Rybak wrote:
>> > Hi,
>> >
>> > I corrected and PLDized RHEL spec for OSsec-hids.
>> > Cause it is my first spec, any help and comments is appreciated :)
>>
>> > #  - warning: Installed (but unpackaged) file(s) found:
>> > #    /var/ossec/bin/ossec-makelists
>> > #    /var/ossec/bin/ossec-regex
>>
>> This path (/var/ossec) is not FHS compliant.
>> Variable package files should be placed in /var/lib/PACKAGE.
>> The above names suggest that the files are not even variable - so should
>> be in /usr/share/PACKAGE, /usr/lib*/PACKAGE (if they are arch-dependent)
>> or /usr/bin (if they are directly callable for user).
>
>
Almost all ossec process chroot to /var/ossec, so this is a reason why
almost everything is located under /var/ossec. If so - is this path FHS
compiliant? Where chroot envs are/should be stored in PLD?

best regards,
---
Marcin Rybak


From lisu87 at gmail.com  Wed Apr 20 15:51:08 2011
From: lisu87 at gmail.com (=?UTF-8?B?TWljaGHFgiBMaXNvd3NraQ==?=)
Date: Wed, 20 Apr 2011 15:51:08 +0200
Subject: ntfs-3g and ntfsprogs merge
Message-ID: <4DAEE4CC.20205@gmail.com>

These two packages are now merged and will be released as 
ntfs-3g_ntfsprogs-version format.

Please cp ntfs-3g to ntfs-3g_ntfsprogs then.


From glen at pld-linux.org  Thu Apr 21 10:00:44 2011
From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Thu, 21 Apr 2011 11:00:44 +0300
Subject: ntfs-3g and ntfsprogs merge
In-Reply-To: <4DAEE4CC.20205@gmail.com>
References: <4DAEE4CC.20205@gmail.com>
Message-ID: <4DAFE42C.8040803@pld-linux.org>

On 20.04.2011 16:51, Micha? Lisowski wrote:
> These two packages are now merged and will be released as 
> ntfs-3g_ntfsprogs-version format.
>
> Please cp ntfs-3g to ntfs-3g_ntfsprogs then.

perhaps too rushy? wait what official upstream decides [1]?
just build -n ntfsprogs package from current ntfs-3g package until it is 
resolved?

or how do you foresee the upgrade path in pld if both package names just 
dissapear?

[1] http://osdir.com/ml/fedora-devel-list/2011-04/msg00081.html

-- 
glen



From lisu87 at gmail.com  Thu Apr 21 10:24:54 2011
From: lisu87 at gmail.com (Michal Lisowski)
Date: Thu, 21 Apr 2011 10:24:54 +0200
Subject: ntfs-3g and ntfsprogs merge
In-Reply-To: <4DAFE42C.8040803@pld-linux.org>
References: <4DAEE4CC.20205@gmail.com> <4DAFE42C.8040803@pld-linux.org>
Message-ID: <4DAFE9D6.5070807@gmail.com>

W dniu 21.04.2011 10:00, Elan Ruusam?e pisze:
> On 20.04.2011 16:51, Micha? Lisowski wrote:
>> These two packages are now merged and will be released as 
>> ntfs-3g_ntfsprogs-version format.
>>
>> Please cp ntfs-3g to ntfs-3g_ntfsprogs then.
>
> perhaps too rushy? wait what official upstream decides [1]?
> just build -n ntfsprogs package from current ntfs-3g package until it 
> is resolved?

it's officialy confirmed as I know:

http://www.tuxera.com/open-source/release-ntfs-3g-ntfsprogs-2011-4-12/

>
> or how do you foresee the upgrade path in pld if both package names 
> just dissapear?

Some Provides and Obsoletes should be sufficient. Correct meif i'm wrong.



From caleb at pld-linux.org  Thu Apr 21 10:50:10 2011
From: caleb at pld-linux.org (Caleb Maclennan)
Date: Thu, 21 Apr 2011 11:50:10 +0300
Subject: ntfs-3g and ntfsprogs merge
In-Reply-To: <4DAFE9D6.5070807@gmail.com>
References: <4DAEE4CC.20205@gmail.com> <4DAFE42C.8040803@pld-linux.org>
	<4DAFE9D6.5070807@gmail.com>
Message-ID: <BANLkTikq3+JiA-bvj1hBBjY+5+L_szMoHQ@mail.gmail.com>

>> or how do you foresee the upgrade path in pld if both package names just
>> dissapear?
>
> Some Provides and Obsoletes should be sufficient. Correct meif i'm wrong.

Yes, the Provides and Obsoletes will take care of being able to
upgrade and replace the previous package names. The problem is that
there is no notification feature for the OLD packages, they just get
stuck at an old version and eventual disappear from the stable package
set. However this is not a unique problem to this issue, it happens
regularly and even I have been known to ask on this list where to find
the "new" package name for something project that morphed into
something else.

I think your request for a spec COPY not a move/rename is appropriate.
People may still need to be able to build the original package for a
while, but work can continue under the new package name.

Caleb


From wolf.pld at gmail.com  Thu Apr 21 11:22:07 2011
From: wolf.pld at gmail.com (Bartosz Taudul)
Date: Thu, 21 Apr 2011 11:22:07 +0200
Subject: ntfs-3g and ntfsprogs merge
In-Reply-To: <BANLkTikq3+JiA-bvj1hBBjY+5+L_szMoHQ@mail.gmail.com>
References: <4DAEE4CC.20205@gmail.com> <4DAFE42C.8040803@pld-linux.org>
	<4DAFE9D6.5070807@gmail.com>
	<BANLkTikq3+JiA-bvj1hBBjY+5+L_szMoHQ@mail.gmail.com>
Message-ID: <BANLkTinbmR7E6fOqduYCUZ3ST+C3XbbK-g@mail.gmail.com>

On Thu, Apr 21, 2011 at 10:50 AM, Caleb Maclennan <caleb at pld-linux.org> wrote:
> Yes, the Provides and Obsoletes will take care of being able to
> upgrade and replace the previous package names. The problem is that
> there is no notification feature for the OLD packages, they just get
> stuck at an old version and eventual disappear from the stable package
> set. However this is not a unique problem to this issue, it happens
> regularly and even I have been known to ask on this list where to find
> the "new" package name for something project that morphed into
> something else.
Maybe we should provide empty rpms for the obsoleted packages with the
appropriate R: and some special name in release field? For example:
ntfs-3g-1.2.3-69.packageexpired, R: ntfs3g-newshit

Then we may have a simple cron job that would do rpm -e `rpm -qa|grep
packageexpired` on a regular basis to remove the obsolete stuff.

wolf


From patrys at pld-linux.org  Thu Apr 21 11:57:10 2011
From: patrys at pld-linux.org (Patryk Zawadzki)
Date: Thu, 21 Apr 2011 11:57:10 +0200
Subject: ntfs-3g and ntfsprogs merge
In-Reply-To: <BANLkTinbmR7E6fOqduYCUZ3ST+C3XbbK-g@mail.gmail.com>
References: <4DAEE4CC.20205@gmail.com> <4DAFE42C.8040803@pld-linux.org>
	<4DAFE9D6.5070807@gmail.com>
	<BANLkTikq3+JiA-bvj1hBBjY+5+L_szMoHQ@mail.gmail.com>
	<BANLkTinbmR7E6fOqduYCUZ3ST+C3XbbK-g@mail.gmail.com>
Message-ID: <BANLkTikXv8q_JgC+LsHrEkrsbMg+ZuRPXQ@mail.gmail.com>

On Thu, Apr 21, 2011 at 11:22 AM, Bartosz Taudul <wolf.pld at gmail.com> wrote:
> Maybe we should provide empty rpms for the obsoleted packages with the
> appropriate R: and some special name in release field? For example:
> ntfs-3g-1.2.3-69.packageexpired, R: ntfs3g-newshit
>
> Then we may have a simple cron job that would do rpm -e `rpm -qa|grep
> packageexpired` on a regular basis to remove the obsolete stuff.

http://cvs.pld-linux.org/cgi-bin/cvsweb/packages/obsoleted/obsoleted.spec?rev=HEAD

It works by building an empty package that marks the upgrade target
and immediately gets obsoleted by said target. There is nothing to
clean up then.

-- 
Patryk Zawadzki
I solve problems.


From caleb at pld-linux.org  Thu Apr 21 12:08:46 2011
From: caleb at pld-linux.org (Caleb Maclennan)
Date: Thu, 21 Apr 2011 13:08:46 +0300
Subject: ntfs-3g and ntfsprogs merge
In-Reply-To: <BANLkTikXv8q_JgC+LsHrEkrsbMg+ZuRPXQ@mail.gmail.com>
References: <4DAEE4CC.20205@gmail.com> <4DAFE42C.8040803@pld-linux.org>
	<4DAFE9D6.5070807@gmail.com>
	<BANLkTikq3+JiA-bvj1hBBjY+5+L_szMoHQ@mail.gmail.com>
	<BANLkTinbmR7E6fOqduYCUZ3ST+C3XbbK-g@mail.gmail.com>
	<BANLkTikXv8q_JgC+LsHrEkrsbMg+ZuRPXQ@mail.gmail.com>
Message-ID: <BANLkTikEX8ggfaJPayXU7ztf-A6r_QGCiA@mail.gmail.com>

> http://cvs.pld-linux.org/cgi-bin/cvsweb/packages/obsoleted/obsoleted.spec?rev=HEAD
>
> It works by building an empty package that marks the upgrade target
> and immediately gets obsoleted by said target. There is nothing to
> clean up then.

Where have you been all my life?


From glen at pld-linux.org  Thu Apr 21 19:39:18 2011
From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Thu, 21 Apr 2011 20:39:18 +0300
Subject: ntfs-3g and ntfsprogs merge
In-Reply-To: <BANLkTinbmR7E6fOqduYCUZ3ST+C3XbbK-g@mail.gmail.com>
References: <4DAEE4CC.20205@gmail.com>
	<4DAFE42C.8040803@pld-linux.org>	<4DAFE9D6.5070807@gmail.com>	<BANLkTikq3+JiA-bvj1hBBjY+5+L_szMoHQ@mail.gmail.com>
	<BANLkTinbmR7E6fOqduYCUZ3ST+C3XbbK-g@mail.gmail.com>
Message-ID: <4DB06BC6.7000805@pld-linux.org>

On 21.04.2011 12:22, Bartosz Taudul wrote:
> On Thu, Apr 21, 2011 at 10:50 AM, Caleb Maclennan<caleb at pld-linux.org>  wrote:
>> Yes, the Provides and Obsoletes will take care of being able to
>> upgrade and replace the previous package names. The problem is that
>> there is no notification feature for the OLD packages, they just get
>> stuck at an old version and eventual disappear from the stable package
>> set. However this is not a unique problem to this issue, it happens
>> regularly and even I have been known to ask on this list where to find
>> the "new" package name for something project that morphed into
>> something else.
> Maybe we should provide empty rpms for the obsoleted packages with the
> appropriate R: and some special name in release field? For example:
> ntfs-3g-1.2.3-69.packageexpired, R: ntfs3g-newshit
>
> Then we may have a simple cron job that would do rpm -e `rpm -qa|grep
> packageexpired` on a regular basis to remove the obsolete stuff.
>
> wolf
id prefer keeping original package names, even in built from different src.rpm.spec

-n ntfsprogs
-n ntfs-3g


or they are not separateable anymore (can't think of ntfs-3g for mount 
tools and ntfsprgs as  fsck tools?)

-- 
glen



From glen at pld-linux.org  Thu Apr 21 19:40:31 2011
From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Thu, 21 Apr 2011 20:40:31 +0300
Subject: ntfs-3g and ntfsprogs merge
In-Reply-To: <4DAFE9D6.5070807@gmail.com>
References: <4DAEE4CC.20205@gmail.com> <4DAFE42C.8040803@pld-linux.org>
	<4DAFE9D6.5070807@gmail.com>
Message-ID: <4DB06C0F.1010609@pld-linux.org>

On 21.04.2011 11:24, Michal Lisowski wrote:
> W dniu 21.04.2011 10:00, Elan Ruusam?e pisze:
>> On 20.04.2011 16:51, Micha? Lisowski wrote:
>>> These two packages are now merged and will be released as 
>>> ntfs-3g_ntfsprogs-version format.
>>>
>>> Please cp ntfs-3g to ntfs-3g_ntfsprogs then.
>>
>> perhaps too rushy? wait what official upstream decides [1]?
>> just build -n ntfsprogs package from current ntfs-3g package until it 
>> is resolved?
>
> it's officialy confirmed as I know:
>
> http://www.tuxera.com/open-source/release-ntfs-3g-ntfsprogs-2011-4-12/

that's response from "takeovers", what's response from old team?
also is the old code (plain ntfsprogs) no longer maintained?

-- 
glen



From lisu87 at gmail.com  Fri Apr 22 10:43:38 2011
From: lisu87 at gmail.com (Michal Lisowski)
Date: Fri, 22 Apr 2011 10:43:38 +0200
Subject: ntfs-3g and ntfsprogs merge
In-Reply-To: <4DB06C0F.1010609@pld-linux.org>
References: <4DAEE4CC.20205@gmail.com>
	<4DAFE42C.8040803@pld-linux.org>	<4DAFE9D6.5070807@gmail.com>
	<4DB06C0F.1010609@pld-linux.org>
Message-ID: <4DB13FBA.5000206@gmail.com>

W dniu 21.04.2011 19:40, Elan Ruusam?e pisze:
> On 21.04.2011 11:24, Michal Lisowski wrote:
>> W dniu 21.04.2011 10:00, Elan Ruusam?e pisze:
>>> On 20.04.2011 16:51, Micha? Lisowski wrote:
>>>> These two packages are now merged and will be released as 
>>>> ntfs-3g_ntfsprogs-version format.
>>>>
>>>> Please cp ntfs-3g to ntfs-3g_ntfsprogs then.
>>>
>>> perhaps too rushy? wait what official upstream decides [1]?
>>> just build -n ntfsprogs package from current ntfs-3g package until 
>>> it is resolved?
>>
>> it's officialy confirmed as I know:
>>
>> http://www.tuxera.com/open-source/release-ntfs-3g-ntfsprogs-2011-4-12/
>
> that's response from "takeovers", what's response from old team?
> also is the old code (plain ntfsprogs) no longer maintained?
>

OK, we can wait for more info if you say so.


From sparky at pld-linux.org  Fri Apr 22 16:24:04 2011
From: sparky at pld-linux.org (Przemyslaw Iskra)
Date: Fri, 22 Apr 2011 16:24:04 +0200
Subject: stop skip_post_check_so abuse !
Message-ID: <20110422142404.GA31438@pld-linux.org>

Please do not:

%define	skip_post_check_so ANYTHING

without a very good reason. The missing-symbols check has been enabled
to detect broken linking and fix it, not to disable it anytime a problem
appears.

Right now there are 45 specs that define skip_post_check_so, only 11 of
them have a comment why it's been disabled, and only 5 of them give a
good reason to disable symbol checking.

Good reasons are:
- binary (no source) package, cannot be relinked
- broken design - circular dependency between libraries
- symbols provided by an executable

If you happen to stumble upon any of the above, please add a descriptive
comment just above %define skip_post_check_so. In any other case
FIX LIBRARY LINKING !


Best regards,
	Przemys?aw Iskra.

-- 
 ____    sparky  --  Przemyslaw  ................ LANG...Pl,Ca,Es,En
/____) ___  ___  _ _ || Iskra   : WWW . http://ppcrcd.pld-linux.org/
\____\| -_)'___| ||^'||//\\//   : WWW2 ............ http://rsget.pl/
(____/||   (_-_|_||  ||\\ ||    : eMail ..... <sparky at pld-linux.org>


From sparky at pld-linux.org  Fri Apr 22 16:36:34 2011
From: sparky at pld-linux.org (Przemyslaw Iskra)
Date: Fri, 22 Apr 2011 16:36:34 +0200
Subject: packages: corosync/corosync.spec - added explanation to
	skip_post_check_so
In-Reply-To: <packages_corosync_corosync.spec.1.15@pld-linux.org>
References: <packages_corosync_corosync.spec.1.14@pld-linux.org>
	<packages_corosync_corosync.spec.1.15@pld-linux.org>
Message-ID: <20110422143634.GA19787@pld-linux.org>

On Fri, Apr 22, 2011 at 04:32:17PM +0200, alucard wrote:
> Author: alucard                      Date: Fri Apr 22 14:32:17 2011 GMT
> Module: packages                      Tag: HEAD
> ---- Log message:
> - added explanation to skip_post_check_so

> -# REASON TO SKIP SO CHECK IS MISSING
> -#%%define		skip_post_check_so	libtotem_pg.so.4.0.0
> +# "Unresolved symbols found: clock_gettime" however -lrt is properly
> +# passed (or seems to me - alucard), corosync works well anyway
> +%define		skip_post_check_so	libtotem_pg.so.4.0.0

No, it isn't:

x86_64-pld-linux-gcc -shared -o libtotem_pg.so.4.0.0 \
        -Wl,-soname=libtotem_pg.so.4 \
		        -Wl,--as-needed -Wl,--no-copy-dt-needed-entries
				-Wl,-z,relro -Wl,-z,combreloc    coropoll.o totemip.o
				totemnet.o totemudp.o totemudpu.o totemrrp.o totemsrp.o
				totemmrp.o totempg.o crypto.o wthread.o -lnss3
				-lnssutil3 -lsmime3 -lssl3 -lsoftokn3 -lplds4 -lplc4
				-lnspr4 -ldl -lc -lpthread     -lpthread



Add $(LIBS) at the end of exec/Makefile.am, line 128, and it should all go
away.

$(CC) -shared -o $@ \
	-Wl,-soname=libtotem_pg.so.$(SOMAJOR) \
	$(LDFLAGS) $^ $(nss_LIBS) $(rdmacm_LIBS) $(ibverbs_LIBS) -lpthread $(LIBS)



Best regards,
	Przemys?aw Iskra.

-- 
 ____    sparky  --  Przemyslaw  ................ LANG...Pl,Ca,Es,En
/____) ___  ___  _ _ || Iskra   : WWW . http://ppcrcd.pld-linux.org/
\____\| -_)'___| ||^'||//\\//   : WWW2 ............ http://rsget.pl/
(____/||   (_-_|_||  ||\\ ||    : eMail ..... <sparky at pld-linux.org>


From alucard at nospheratu.net  Fri Apr 22 17:06:41 2011
From: alucard at nospheratu.net (Tomasz Rutkowski)
Date: Fri, 22 Apr 2011 17:06:41 +0200
Subject: packages: corosync/corosync.spec - added explanation to
	skip_post_check_so
In-Reply-To: <20110422143634.GA19787@pld-linux.org>
References: <packages_corosync_corosync.spec.1.14@pld-linux.org>
	<packages_corosync_corosync.spec.1.15@pld-linux.org>
	<20110422143634.GA19787@pld-linux.org>
Message-ID: <1303484802.3509.1.camel@battleship>

Dnia 2011-04-22, pi? o godzinie 16:36 +0200, Przemyslaw Iskra pisze:
> On Fri, Apr 22, 2011 at 04:32:17PM +0200, alucard wrote:
> > Author: alucard                      Date: Fri Apr 22 14:32:17 2011 GMT
> > Module: packages                      Tag: HEAD
> > ---- Log message:
> > - added explanation to skip_post_check_so
> 
> > -# REASON TO SKIP SO CHECK IS MISSING
> > -#%%define		skip_post_check_so	libtotem_pg.so.4.0.0
> > +# "Unresolved symbols found: clock_gettime" however -lrt is properly
> > +# passed (or seems to me - alucard), corosync works well anyway
> > +%define		skip_post_check_so	libtotem_pg.so.4.0.0
> 
> No, it isn't:
> 

[...]

yup, I get it now...
fixed and thanks


-- 
------------------------------------------------------------------------
Tomasz Rutkowski , +48 604 419 913 , e-mail/xmpp: alucard at nospheratu.net
------------------------------------------------------------------------



From jajcus at jajcus.net  Mon Apr 25 22:36:35 2011
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Mon, 25 Apr 2011 22:36:35 +0200
Subject: Erlang broken - no pgsql modules
Message-ID: <20110425203635.GA12670@lolek.nigdzie>


I have just upgraded my system hosting a jabber server and ejabberd
failed with:

=ERROR REPORT==== 2011-04-25 22:29:38 ===
C(<0.37.0>:ejabberd_check:63) : ejabberd is configured to use 'pgsql', but the following Erlang modules are not installed: '[pgsql_proto,

                                             pgsql_tcp,

                                             pgsql_util]'


# rpm -q erlang 
erlang-R14B01-1.i686

Downgrade to erlang-R13B04-4.i686 fixed the problem.

Greets,
        Jacek


From jajcus at jajcus.net  Mon Apr 25 22:50:35 2011
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Mon, 25 Apr 2011 22:50:35 +0200
Subject: Erlang broken - no pgsql modules
In-Reply-To: <20110425203635.GA12670@lolek.nigdzie>
References: <20110425203635.GA12670@lolek.nigdzie>
Message-ID: <20110425205035.GB12670@lolek.nigdzie>

On Mon, Apr 25, 2011 at 10:36:35PM +0200, Jacek Konieczny wrote:
> Downgrade to erlang-R13B04-4.i686 fixed the problem.

Not quite :-(

Now ejabberd starts, but won't authorize users. Something is still wrong
with the database interface.

Greets,
        Jacek


From jajcus at jajcus.net  Tue Apr 26 08:23:25 2011
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Tue, 26 Apr 2011 08:23:25 +0200
Subject: Erlang broken - no pgsql modules
In-Reply-To: <20110425205035.GB12670@lolek.nigdzie>
References: <20110425203635.GA12670@lolek.nigdzie>
	<20110425205035.GB12670@lolek.nigdzie>
Message-ID: <20110426062232.GA11050@jajo.eggsoft>

On Mon, Apr 25, 2011 at 10:50:35PM +0200, Jacek Konieczny wrote:
> On Mon, Apr 25, 2011 at 10:36:35PM +0200, Jacek Konieczny wrote:
> > Downgrade to erlang-R13B04-4.i686 fixed the problem.
> 
> Not quite :-(
> 
> Now ejabberd starts, but won't authorize users. Something is still wrong
> with the database interface.

I was able to make ejabberd work with the older Erlang and PostgreSQL 9
doing this: http://www.ejabberd.im/node/4526#comment-57062

I will try to fix it with current Erlang and ejabberd later today.

Greets,
        Jacek


From jajcus at jajcus.net  Tue Apr 26 11:05:10 2011
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Tue, 26 Apr 2011 11:05:10 +0200
Subject: Erlang broken - no pgsql modules
In-Reply-To: <20110425203635.GA12670@lolek.nigdzie>
References: <20110425203635.GA12670@lolek.nigdzie>
Message-ID: <20110426090510.GB11050@jajo.eggsoft>

On Mon, Apr 25, 2011 at 10:36:35PM +0200, Jacek Konieczny wrote:
> 
> I have just upgraded my system hosting a jabber server and ejabberd
> failed with:
> 
> =ERROR REPORT==== 2011-04-25 22:29:38 ===
> C(<0.37.0>:ejabberd_check:63) : ejabberd is configured to use 'pgsql', but the following Erlang modules are not installed: '[pgsql_proto,
> 
>                                              pgsql_tcp,
> 
>                                              pgsql_util]'
> 
> 
> # rpm -q erlang 
> erlang-R14B01-1.i686
> 
> Downgrade to erlang-R13B04-4.i686 fixed the problem.

Problem solved. It was a false alarm. I have been using a 'pgsql' module
which was not included in our ejabberd. As it was not compiled with
current Erlang it stopped working after Erlang upgrade. And it was old
enough to stop working with current PostgreSQL too.

I have added the current pgsql module to our ejabberd package ? this
should solve similar problems on future upgrade too :)

Greets,
        Jacek


From marcin.rybak at gmail.com  Tue Apr 26 16:18:41 2011
From: marcin.rybak at gmail.com (Marcin Rybak)
Date: Tue, 26 Apr 2011 16:18:41 +0200
Subject: what provides javac
Message-ID: <BANLkTin65anXiX=iZxGbMOuzeaxK_EZWMA@mail.gmail.com>

Hi,

I tried to build tzdata on my own builder (clean machine with almost no
packages installed) but:

/usr/lib/jvm/jre/bin/javac: not found

so - buildrequire is not complete (or maybe it shouldn't be... cause many
packages provides javac?).

I've checked at carme (i686 and 64):
rpm -qf /usr/bin/javac
icedtea6-jdk-1.8.3-1
lrwxrwxrwx 1 root root 39 11-28 14:00 /usr/bin/javac ->
/usr/lib64/jvm/icedtea6-1.8.3/bin/javac

Is it always exact?
carme ti:
rpm -qf /usr/bin/javac
java-gcj-compat-devel-1.0.78-9.x86_64
lrwxrwxrwx 1 root root 48 Mar  5  2010 /usr/bin/javac ->
/usr/lib64/java/java-1.5.0-gcj-1.5.0.0/bin/javac

different ti machine:
rpm -qf /usr/bin/javac
java-sun-1.6.0.22-1.i686
lrwxrwxrwx 1 root root 40 Mar  5 00:08 /usr/bin/javac ->
/usr/lib/jvm/java-sun-1.6.0.22/bin/javac

so - what package really provides target of /usr/bin/javac symlink? (looks
like: java-gcj-compat-devel - but let me ask is it the only way?)

Thanks for help
---
Marcin


From qboosh at pld-linux.org  Tue Apr 26 19:37:29 2011
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Tue, 26 Apr 2011 19:37:29 +0200
Subject: packages: filesystem/filesystem.spec - rel 43; add /run
In-Reply-To: <packages_filesystem_filesystem.spec.1.123@pld-linux.org>
References: <packages_filesystem_filesystem.spec.1.122@pld-linux.org>
	<packages_filesystem_filesystem.spec.1.123@pld-linux.org>
Message-ID: <20110426173729.GB4408@stranger.qboosh.pl>

On Sun, Apr 03, 2011 at 02:10:29PM +0200, arekm wrote:
> Author: arekm                        Date: Sun Apr  3 12:10:29 2011 GMT
> Module: packages                      Tag: HEAD
> ---- Log message:
> - rel 43; add /run

What is this?


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


From patrys at pld-linux.org  Tue Apr 26 19:43:47 2011
From: patrys at pld-linux.org (Patryk Zawadzki)
Date: Tue, 26 Apr 2011 19:43:47 +0200
Subject: packages: filesystem/filesystem.spec - rel 43; add /run
In-Reply-To: <20110426173729.GB4408@stranger.qboosh.pl>
References: <packages_filesystem_filesystem.spec.1.122@pld-linux.org>
	<packages_filesystem_filesystem.spec.1.123@pld-linux.org>
	<20110426173729.GB4408@stranger.qboosh.pl>
Message-ID: <BANLkTi=KKTgW=eA+-deKGFZXkeqORejXLQ@mail.gmail.com>

On Tue, Apr 26, 2011 at 7:37 PM, Jakub Bogusz <qboosh at pld-linux.org> wrote:
> On Sun, Apr 03, 2011 at 02:10:29PM +0200, arekm wrote:
>> Author: arekm ? ? ? ? ? ? ? ? ? ? ? ?Date: Sun Apr ?3 12:10:29 2011 GMT
>> Module: packages ? ? ? ? ? ? ? ? ? ? ?Tag: HEAD
>> ---- Log message:
>> - rel 43; add /run
> What is this?

http://lists.fedoraproject.org/pipermail/devel/2011-March/150031.html

-- 
Patryk Zawadzki
I solve problems.


From megabajt at pld-linux.org  Tue Apr 26 19:44:56 2011
From: megabajt at pld-linux.org (Marcin Banasiak)
Date: Tue, 26 Apr 2011 19:44:56 +0200
Subject: what provides javac
In-Reply-To: <BANLkTin65anXiX=iZxGbMOuzeaxK_EZWMA@mail.gmail.com>
References: <BANLkTin65anXiX=iZxGbMOuzeaxK_EZWMA@mail.gmail.com>
Message-ID: <BANLkTim6qzV1CvfswZ8h58dTFZcNaUxmFw@mail.gmail.com>

2011/4/26 Marcin Rybak:
> so - what package really provides target of /usr/bin/javac symlink? (looks
> like: java-gcj-compat-devel - but let me ask is it the only way?)

javac is provided by multiple packages, for example on Th:

poldek:/all-avail> search -f /usr/bin/javac
4 package(s) found:
icedtea6-jdk-1.8.3-1.i686
java-gcj-compat-devel-1.0.80-8.i686
java-sun-1.6.0.24-1.i686
java5-sun-1.5.0.22-2.i686

To handle this case in spec file you should require jdk, which is
provided by all these packages.

-- 
Marcin Banasiak


From glen at pld-linux.org  Wed Apr 27 10:55:48 2011
From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Wed, 27 Apr 2011 11:55:48 +0300
Subject: what provides javac
In-Reply-To: <BANLkTim6qzV1CvfswZ8h58dTFZcNaUxmFw@mail.gmail.com>
References: <BANLkTin65anXiX=iZxGbMOuzeaxK_EZWMA@mail.gmail.com>
	<BANLkTim6qzV1CvfswZ8h58dTFZcNaUxmFw@mail.gmail.com>
Message-ID: <4DB7DA14.2070108@pld-linux.org>

On 26.04.2011 20:44, Marcin Banasiak wrote:
> 2011/4/26 Marcin Rybak:
>> so - what package really provides target of /usr/bin/javac symlink? (looks
>> like: java-gcj-compat-devel - but let me ask is it the only way?)
> javac is provided by multiple packages, for example on Th:
>
> poldek:/all-avail>  search -f /usr/bin/javac
> 4 package(s) found:
> icedtea6-jdk-1.8.3-1.i686
> java-gcj-compat-devel-1.0.80-8.i686
> java-sun-1.6.0.24-1.i686
> java5-sun-1.5.0.22-2.i686
>
> To handle this case in spec file you should require jdk, which is
> provided by all these packages.

added missing BR

-- 
glen



From udvzsolt at gmail.com  Sat Apr 30 18:11:09 2011
From: udvzsolt at gmail.com (Zsolt Udvari)
Date: Sat, 30 Apr 2011 18:11:09 +0200
Subject: fglrx
Message-ID: <BANLkTimx-heX0+ZFowEjD-y8O9ba4vNYVQ@mail.gmail.com>

Hi all!

===================================================================
RCS file: /cvsroot/packages/xorg-driver-video-fglrx/xorg-driver-video-fglrx.spec,v
retrieving revision 1.232
retrieving revision 1.233
diff -u -p -r1.232 -r1.233
--- xorg-driver-video-fglrx.spec	2011/04/20 16:28:43	1.232
+++ xorg-driver-video-fglrx.spec	2011/04/20 21:02:21	1.233
.....
+Revision 1.233  2011/04/20 21:02:21  august84
+- build fixed; real rel 1 for old xserver



And what about newer xserver?

Zsolt