J Yeah… this is kind of the way we work with PLD – people who use it
usually know well how it workd. But any help with documentation is
welcome. PLD Linux is usually installed manually via chroot. PLD Rescue
CD (http://rescuecd.pld-linux.org/) is usually used for that, but I will
soon announce
On Sun, 10 Nov 2013 13:48:46 +0100
Roelof Wobben wrote:
> I like to try this distro.
Nice to hear that.
> But is there no installation manual and a manual how to keep PLD
> up-to-date ?
Yeah… this is kind of the way we work with PLD – people who use it
usually know well how it workd. But any h
Hello,
I like to try this distro.
But is there no installation manual and a manual how to keep PLD
up-to-date ?
And which bootloader does PLD uses ?
Roelof
---
Dit e-mailbericht bevat geen virussen en malware omdat avast! Antivirus actief
is.
http://www.avast.com
__
On Sat, 01 Dec 2012, Jeffrey Johnson wrote:
> (aside)
> Good: The behavior is symmetric when permuted.
>
> The documentation states that $1/$2 are the number of pkg instances
> after the script is run. This isn't precise enough a definition
> when there is an ACID transaction with a 2phase commit
On Dec 1, 2012, at 10:55 AM, Jeffrey Johnson wrote:
>
> I'm inclined atm to prefer the above actual behavior to "fudging" an
> extra +1 for "legacy compatible" behavior; I'm sure we disagree here.
>
> Short answer: patch in an extra +1 (there will be two code paths in need
> of patching, check
On Dec 1, 2012, at 6:23 AM, Jeffrey Johnson wrote:
>>
>> Both permutations are wrong, $1 and $2 should be 1 in both cases.
>>
>> [root@sith RPMS]# rpm -Uvh test-0.1-0.1.noarch.rpm
>> Preparing...###
>> [100%]
>> 1:test
On Dec 1, 2012, at 4:47 AM, Jan Rękorajski wrote:
> On Fri, 30 Nov 2012, Jeffrey Johnson wrote:
>
>> Try each of the 2 order permutations.
>>
>> FWIW the behavior of triggers from already installed packages when both
>> Packages are in the same transaction
>> Has _NEVER_ been documented anywhe
On Fri, 30 Nov 2012, Jeffrey Johnson wrote:
> Try each of the 2 order permutations.
>
> FWIW the behavior of triggers from already installed packages when both
> Packages are in the same transaction
> Has _NEVER_ been documented anywhere I am aware of precisely.
As I understand the docs, it shou
Try each of the 2 order permutations.
FWIW the behavior of triggers from already installed packages when both
Packages are in the same transaction
Has _NEVER_ been documented anywhere I am aware of precisely.
I'll actually try the test.spec if my guess above isn't correct ;-)
73 de Jeff
Sent fr
On Fri, 30 Nov 2012, Jeffrey Johnson wrote:
>
> On Nov 30, 2012, at 3:47 PM, Jan Rękorajski wrote:
>
> > BTW, did you look into the problem with triggers arguments?
> >
>
> Nope. I have yet to be convinced of what the root
> cause is: all you have been telling me is that
> RPM5 is buggy
On Nov 30, 2012, at 3:47 PM, Jan Rękorajski wrote:
>>
>> If this is the real problem, then the fix for infinite looping
>> has little to do with namespaces at all.
>>
>> Yes: the iterator loop index on dependency sets is global.
>>
>> Which means that if something decrements the iterator inde
On Fri, 30 Nov 2012, Jeffrey Johnson wrote:
>
> On Nov 30, 2012, at 2:53 PM, Jan Rękorajski wrote:
>
> > On Fri, 30 Nov 2012, Jeffrey Johnson wrote:
> >
> > The real problem that I was afraid to touch to avoid messing things up
> > is lib/rpmal.c:rpmalAllSatisfiesDepend() which seems to work on
On Nov 30, 2012, at 2:53 PM, Jan Rękorajski wrote:
> On Fri, 30 Nov 2012, Jeffrey Johnson wrote:
>
> The real problem that I was afraid to touch to avoid messing things up
> is lib/rpmal.c:rpmalAllSatisfiesDepend() which seems to work on global
> lists instead of private copies which caused the
On Nov 30, 2012, at 2:43 PM, Jan Rękorajski wrote:
> On Fri, 30 Nov 2012, Jeffrey Johnson wrote:
>
>>
>> On Nov 30, 2012, at 8:57 AM, Jeffrey Johnson wrote:
>>
>>>
>>> The actual namespace and the intended semantic should be identified also:
>>> PLD is doing something different than other di
On Fri, 30 Nov 2012, Jeffrey Johnson wrote:
>
> On Nov 30, 2012, at 7:41 AM, Jan Rękorajski wrote:
>
> >
> > And so it happens that the problem had nothing to do with database, see
> > http://git.pld-linux.org/?
>
> Well it has nothing to do with Berkeley DB, but …
>
> > p=packages/rpm.git;a
On Fri, 30 Nov 2012, Jeffrey Johnson wrote:
>
> On Nov 30, 2012, at 8:57 AM, Jeffrey Johnson wrote:
>
> >
> > The actual namespace and the intended semantic should be identified also:
> > PLD is doing something different than other distros.
> >
>
> From git log
> This patch fixes a bug with
On Nov 30, 2012, at 8:57 AM, Jeffrey Johnson wrote:
>
> The actual namespace and the intended semantic should be identified also:
> PLD is doing something different than other distros.
>
>From git log
This patch fixes a bug with ntpd package we encoutered:
- ntpdate has "Conflicts: ntp < 4.2.
On Nov 30, 2012, at 7:41 AM, Jan Rękorajski wrote:
>
> And so it happens that the problem had nothing to do with database, see
> http://git.pld-linux.org/?
Well it has nothing to do with Berkeley DB, but …
> p=packages/rpm.git;a=commit;h=d2ec8f01d4cbb82f79d8abc51f26506a58162d9c
> for gory det
On Mon, 22 Oct 2012, Elan Ruusamäe wrote:
> Script started on Sun 21 Oct 2012 11:56:39 PM EEST
> # rpm -Uhv ntpd-4.2.6p5-5.i686.rpm
[...]
> D: opening db index /var/lib/rpm/Conflictname
> thread:rdonly:auto_commit mode=0x0
> D: Conflicts: ntp < 4.2.0-3 NO
>
On Oct 22, 2012, at 4:01 PM, Jeffrey Johnson wrote:
>
> On Oct 22, 2012, at 2:57 PM, Elan Ruusamäe wrote:
>
>> On 10/22/2012 05:58 PM, Jeffrey Johnson wrote:
>>> For a suspected database error in the Conflictname index,
>>> then comparing the outputs with
>>>
>>> /usr/lib/rpm/macros:%_dbi_conf
On Oct 22, 2012, at 2:57 PM, Elan Ruusamäe wrote:
> On 10/22/2012 05:58 PM, Jeffrey Johnson wrote:
>> For a suspected database error in the Conflictname index,
>> then comparing the outputs with
>>
>> /usr/lib/rpm/macros:%_dbi_config_3_Conflictname %{_dbi_btconfig}
>> %{?_bt_dupsort} debug
On 10/22/2012 05:58 PM, Jeffrey Johnson wrote:
For a suspected database error in the Conflictname index,
then comparing the outputs with
/usr/lib/rpm/macros:%_dbi_config_3_Conflictname %{_dbi_btconfig}
%{?_bt_dupsort} debug
may be informative. The access patterns SHOULD be similar.
first
On Oct 22, 2012, at 4:07 AM, Elan Ruusamäe wrote:
>
> ps: i have no idea who is mancoosi, or what he identified, you should had
> provided link to that, not assume everybody knows your friends
;-)
Mancoosi was a 3y EU funded research project
http://mancoosi.org
One of the difference
On Oct 22, 2012, at 10:21 AM, Elan Ruusamäe wrote:
> On 22.10.2012 04:46, Jeffrey Johnson wrote:
>> There are too may possible causes to hazard a guess, including
>> a well documented difference in behavior detected by Mancoosi years
>> ago, and also identifying precisely what metadata (and
>> w
On 22.10.2012 04:46, Jeffrey Johnson wrote:
There are too may possible causes to hazard a guess, including
a well documented difference in behavior detected by Mancoosi years
ago, and also identifying precisely what metadata (and
what rpm version was used to build all the packages).
rpm version
On 22.10.2012 04:46, Jeffrey Johnson wrote:
On Oct 21, 2012, at 5:04 PM, Elan Ruusamäe wrote:
NO
D: Conflicts: ntp < 4.2.0-3 NO
^CD: Exiting on signal(0x2) …
This report does nothing except document the existence.
that's how it starts
On Oct 21, 2012, at 5:04 PM, Elan Ruusamäe wrote:
> NO
> D: Conflicts: ntp < 4.2.0-3 NO
> ^CD: Exiting on signal(0x2) …
This report does nothing except document the existence.
There are too may possible causes to hazard a guess, includi
Script started on Sun 21 Oct 2012 11:56:39 PM EEST
# rpm -Uhv ntpd-4.2.6p5-5.i686.rpm
D: pool fd: created size 212 limit -1 flags 0
D: pool iob:created size 24 limit -1 flags 0
D: pool mire: created size 88 limit -1 flags 0
D: pool lua:created size 36 limit -1 flags 0
D: pool ts:
28 matches
Mail list logo
