Author: glen Date: Tue Sep 20 22:26:29 2005 GMT
Module: SPECS Tag: HEAD
Log message:
- removed php-odbtp package, there's php-pecl-odbtp available (if there's
reason for otherwise, please revert and state what's the difference, or fix
the versions are same, 1.1.2. and diff between them shows nothing.
Yeah, but php-pecl-odbtp is still a rip and in the past it wasn't
updated right after new release of original odbtp. If such situation
will occur again we may (hipotetically) end up with old odbtp php module
which may not work
Author: glen Date: Thu Sep 29 17:30:05 2005 GMT
Module: SOURCES Tag: HEAD
Log message:
- from my experience: no cron should be set to run between 03:00 and 04:00, as
the DST changes could either skip or run twice the crons. change monthly
The time has almost come.
That can't be... ;)
There will be one more bigger move from ready to main but it will be the last
one. Futher updates to main tree won't be allowed unless it's important
bugfix or missing package.
And we'll finish the way Ra did.
If installer isn't (and won't)
How about You using NEST instead of PLD?
Go and grep some list archives to learn what was philosophy of NEST and
what was proposed for Th. It was something completly different. Making
Th always in developement doesn't mean making Th always unstable.
M.
Ra was OK as stable system for servers for about a year.
Ac should be released two years ago ;)
Thats true, Ra was _very_ stable... and still is :) I hope that
releasing Th will take us less time than releasing Ac :) I'm just
worried that one maybe two years after relesing Ac almost everyone
It's ok as long, as we make ISO-s from time to time.
That is the part of always in developement idea.
I can't see what's
bothering ppl bout dying ac and th. Windows 98 and 95 and ME died as well,
other distros also make new versions and move on forward.
For me personally if we will
But think about big transitions, such as gcc - when most of
C++/Fortran/Ada/GCJ-based Java stuff must be rebuilt. And many programs
appear broken, so they wouldn't exist in distro even for few months.
All those programs will not exist, but just in devel tree on ftp. They
however will still
Have you seen a distro that supports full machine upgrade (incl.
configuration fixes/rewrites) in less than one night ?
Of course not, but less differences == less time in server room. Which
leads me to conclusion: no matter what philosophy we will choose we
should be releasing stable
Well... we can see Ac as such development tree for gcc/glibc transition
after Ra. Ac hasn't been released yet not because it was too early to
release something new, but because it was never considered complete...
The truth for me is that Ac wasn't released yet because most of us are
Take a look at amavisd-new config file - it's de facto a piece of perl
code you must rewrite. Have you got any idea how to automate process of
upgrading it? It takes me about an hour.
No, you don't need to rewrite it with each upgrade. I'm using
amavisd-new for +/- two years and I had to do
Just to be sure:
You do not try to replace an existing dir by symling during upgrade, do you?
Dunno. Thats glen change, not mine. I've just tested it and everything
went ok.
M.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
That's actually a good thing. PHP5.0 is buggy and seriously broken from
the coder's point of view (me) and causes proper code to behave badly
under some circumstances.
I'm not php programmer so maybe php5.0 is buggy, I don't know and I
don't care. But it is impossible in even medium sized
Is spec ready?
It builds, so probably it is. But I didn't looked whats inside.
Does it work well with 6.9? If yes then it can since we now use
some beta afaik.
Yup. I'm using it with GF MX2 in work. Xorg 6.9 of course.
M.
___
pld-devel-en mailing
I'll give you info when builder request access will be restricted - that
should be good time to update installer.
OK.
No problem but remember that DVD images also needs to be generated and we now
handle ppc boot able isos/dvds, too (using ppcrcd). I've updated generation
scripts in cvs
Because that script was using rescue-cd which doesn't work on i386 machines.
The case with bootdisks is different right?
Right. All bootdisks are built for i386 :)
M.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
Hawk, it's good time for ISOs/DVDs with RC1 now :)
I'll adjust installer tomorrow... err... today :)
+1 day for testing if all installation types works.
+1 day (probably) to adjust and check iso-priority.
+few days for generating and testing ISOs (I don't want to release not
working ones).
Has anyone noticed such thing?
├─crond(25902)─┬─crond(3487)───sh(3488)
# ps aux|grep 3488
root 3488 0.0 0.0 0 0 ?Zs 12:00 0:00 [sh]
defunct
and it seems that jobs aren't run correctly after that. Restarting crond
cures
the problem but only
Should I revert it?
I already reverted it :)
M.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
what about cvsweb 3.0.5?
I will look at it today or tomorrow.
M.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
then it would also match wrong apache (apache1)
Blah... :/
but if you're turning
auto-ac-apache-2_0_55-3_2 into a branch, fix also wrong Provide:
Provides: apache(mod_autoindex)
it doesn't contain it. must be copy paste error.
I guess it will be easier for me to branch it as APACHE_2_0
imap and imap-pop3 packages already require openssl, so there is no need
for imap-common to own this directory.
I'll fix it and move certs.
Also, some time ago /etc/certs directory has been chosen for this
purpose.
$ rpm -qf /etc/certs
FHS-2.3-13
I assume all certs should go there then?
Investigation in progress. BTW, what's that (causes t/op/stat.t failures
sometimes)?
Dunno. However it always fail at regen test (or something) number 25,
30, 167 (randomly) + it always passes all tests when built on root.
M.
___
pld-devel-en
error: abiword-2.4.2-1: req libwv-1.0.so.3 not found
abiword is in progress, I hope to finish it today
error: bigsister-1.02-3: req perl(BS_win32) not found
error: bigsister-oracle-1.02-3: req perl-DBD-Oracle not found
use rel 4, it was built two days ago
error: kdevelop-i18n-3.5.2-1: req
how this all relates to subversion repository and claims that
you always need complete changelog?
But we don't build any rpms from subversion?
M.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
but while we were discussing migration to svn it was stated
that we really need complete changelog. always.
Wait a second. I got lost. Glen wants to cut changelog in CVS/SVN or in
packages at build time? If in specs, then some of them have already been
cut manually. If in rpms, isn't it
in binary rpm's. why pointless?
Few KB more or less per rpm makes no difference for me.
changelog isn't compressed, and some small packages have more in changelog in
Small packages usually doesn't have big changelogs. Of course there are
exceptions.
truncating specfile changelog just to
oh, and this one too. if the changelog is complete, the filelist is 30 pages
far away, comparing to on next page
I'm using mc if I must browse rpm contents :)
M.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
So? I said it makes difference _for me_.
Please read between lines...
It makes no difference for me == I don't care == (you may completly
remove changelogs from rpms || you may keep 10MB changelog in each rpm)
EOT
M.
___
pld-devel-en mailing list
Since Mozilla Suite got an EOL I'm thinking about removing it from Ac.
Why? Any potential security issues or bugs that could be found in near
or far future will not be fixed. So some day we may end with outdated,
buggy, insecure package which can't be updated/patched/fixed. It could
be even
Since Mozilla Suite got an EOL I'm thinking about removing it from Ac.
NOOO!!
Take it easy :) Seamonkey seems to be quite usable ATM. And Mozilla
Suite is dead. Sad but true :(
poldek:/all-avail ls *seamonkey*
błąd: *seamonkey*: no such package or directory
poldek:/all-avail
I
Which package is going to provide system-wide (i.e. in %{_libdir}) gecko
libs?
Depends which one we will decide to use for building mozilla related
specs. Either firefox or seamonkey.
BTW, IIRC Debian replaced mozilla suite with xulrunner.
I'll have a look at it. Maybe we will be able to do
Do you have mozilla-libs or other gecko-based libraries installed?
Probably you have 0 or =2 packages which provide offending library
and package name dependency is not added in such case.
I'm blind, as usual. On my builder I've mozilla-1.7.13-2 packages where
libs were moved from /usr/lib to
I'm using mozilla and firefox isn't what I like. Maybe seamonkey can
replace it but if you're talking about switch - show it first :)
SeaMonkey is now in ready.
M.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
+URL:http://www.mozilla.org/projects/xulrunner/
404 not found
Fixed.
M.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
BTW, there was mozilla-xulrunner.spec already.
Ooops! Which one we should kill then? Or maybe some merge?
M.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
great. so it seems that this is the project, which galeon and
epiphany should be compiled against.
any comments?
Both of them were incompatible with xulrunners typeahead feature. Galeon
was fixed, but epiphany wasn't. And also both xulrunner specs should be
reviewed/merged before using it
mozilla.spec
mozilla-firefox.spec
mozilla-thunderbird.spec
so it should be called mozilla-xulrunner.spec, imho
regards,
On www.mozilla.org pages projects are referred as:
Mozilla Firefox Project
Mozilla Thunderbird Project
The SeaMonkey Project
XULRunner
So IMO it should be
what version of epiphany?
Tested both HEAD and AC-branch yesterday. They both were failing at
./configure.
M.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
but the packages are still grouped, to avoid name collision or just easier to
locate them. or have strict naming (php-{pecl,pear}-, perl-}
They are not grouped. They are all separate packages and does not share
any files/libs. And SeaMonkey for example is even not maintained by
Mozilla AFAIK.
Hello.
There are currently some broken dependencies in yesterday gnome upgrade.
Unfortunatelly ppc builder is currently unreachable (no route to host)
so it may take some time before fixed packages will go to main. I hope
it will be tomorrow. Please be patient.
If you will find some gnome
Hello.
Some packages were today removed from Ac. If someone wants them back, he
should fix issues listed below (if possible).
- php-pear-MDB2_Driver_fbsql
depends on nonexistent php-fbsql package
- php-pear-MDB2_Driver_oci8
depends on php-oci8 which is not built for Ac (and will probably never
Hello.
SquirrelMail 1.4.6-2 will be sent to ready today and will go to main in
few days. Its nothing unusual, but this version has been cut into more
packages. All additional plugins (except compatibility) were removed
from main SquirrelMail package. Depending on your configuration it may
be
PLD kernel team has finally made 2.6.16 version working. Since it
removes serious bug of previous release (machines were randomly hanging
on smp version) I've decided to include it in distribution without
waiting for 2.6.17 (which doesn't have full patch set yet). For now
release 2.6.16.22-2 is in
Rebuilt, with 2.4.33.1 patch applied (which fixes one security bug and
few oopses/panics)
Has anyone tried it?
I've installed it today on few machines. I'll give them few days for
testing.
5 days without problems on production machines. Seems to work OK.
M.
And I'm preparing next release now :/
CVE-2006-3745 fix (i.e. 2.4.33.2 patch) + squashfs update to 3.1.
I hope to commit it today.
BTW, why 2.4.33.2 without EXTRAVERSION chunk?
M.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
I wrote many times that I'll do my best to release Ac stable before
October 2006. Since its two weeks from now its time to decide if I'll do
it or not. Because of that I'm asking all developers: do you think that
current Ac main is ready to be released as stable? If not, why?
If I'll decide to
The problem will be visible in future versions in case of alpha I guess.
We will adapt ;)
M.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Hello.
I've decided to make following two changes in Ac:
1. Mozilla Suite will be completly removed from Ac. It is not maintained
anymore, it already has few security bugs, it will never be updated.
SeaMonkey which is replacement for Mozilla works just fine. All Mozilla
dependent stuff will be
Is 1.1.18 OK for Ac?
+1 from me if upgrade + required rebuilds will be finished before december.
M.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
2. also glibc-amd64 uprade had failed ok (to prevent future problems that
should be still done)
Done.
M.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Haven't they been already downloaded for HEAD?
Hm. They were downladed for HEAD indeed. Sorry, my fault, I was sure
that I'll get message saying already got blah blah.
BTW, storing plain text files in distfiles should be avoided.
True. I'll move them to SOURCES.
M.
error: libpq.so.4 is required by pure-ftpd-1.0.21-1
sent (release 2)
Please don't STBR anything PostgreSQL related. I'm already processing
those packages.
M.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
Hello.
PL:
rekall.spec nie buduje sie na aktualnym Ac.
http://buildlogs.pld-linux.org/index.php?dist=acarch=i686ok=0id=9274ed772715c2f18d76b6018028c9a7
Szybkie zapytanie googli stwierdzilo, ze winne moze byc binutils lub
gcc. Ja sie nie podejmuje naprawy tego. Poza tym wersja w specu (2.2.3)
It looks like classic kde's libtool/autoconf 2.60/pdksh issue.
Try to apply kde-ac260-lt.patch.
It helped. Thanks. Just STBRed. If it will build then PostgreSQL 8.2
will have clear way to main tree :)
M.
___
pld-devel-en mailing list
It helped. Thanks. Just STBRed.
Blah. amd64 failed :( Any ideas for this one?
http://buildlogs.pld-linux.org/index.php?dist=acarch=amd64ok=0id=034b97312cd4e12ba70fc02b5444dbe9
M.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
But you know that without this change php 5.2 builds without
gd_image_rotate?
Uhm. Didn't knew that :( So we no longer can have gd_image_rotate in
both php and php4? Anyway, php4 rebuild is now more important for Ac
than fixing gd_image_rotate in php 5.
M.
I've been trying to get galeon running with xulrunner, w/o success. It
compiles cleanly, but it crashes right after displaying browser window.
The weird thing is when I try to debug the problem with gdb it doesn't
crash. Someone have an idea for source of such behaviour?
BTW: galeon requires
It looks like some race condition between threads.
Never mind, packaging *.manifest files fixed this problem :)
M.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Yes, it is. No releases are made however, just snapshots from trunk.
Maybe we should use one? I'll give it a try.
Oops! These are binary ones. I'll try to google out some security
patches for 1.8.0.4 instead.
M.
___
pld-devel-en mailing list
Cons:
- ? I have no idea what to put here :)
There is one. I've encountered some UP hardware where running any SMP
kernel simply locks whole machine. No boot messages, no errors. That was
also reason why Ra and Ac bootdisks weren't based on SMP kernels.
M.
Good to know the hint is that simple, but still, this blows up a few
systems after upgrade. Which is not good.
Not really. Kernel upgrade process produces romfs which is working
(tested today). Only manually invoked geninitrd doesn't produce romfs
initrd.
M.
what about AC-branch, RA-branch and other branches that weren't
converted to utf?
AC-branch remains non UTF until rpm will handle UTF specs properly at
least on en_US and all pl_PL locales.
M.
___
pld-devel-en mailing list
Since I've upgraded to KDE 3.5.6 Konsole windows aren't grouped anymore.
Anyone knows if this is a bug or new feature? I can't see any new option
in KDE Control Center or Konsole itself to change this behaviour. This
is very annoying when you have 30+ konsole windows which are not grouped
on task
Try rebuilding kdebase without -grouplayer.patch and report back :)
Tried that already. No change.
M.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
EN: Following packages doesn't build on current Ac and will be removed from
distribution if no one will fix them till 10th of March 2007.
PL: Nastepujace pakiety nie buduja sie na aktualnym Ac i zostana usuniete z
dystrybucji jezeli ktos nie poprawi ich do 10 marca 2007.
EN: If there will be more (some packages are still being or will be checked by
me) I'll let you know.
PL: Jezeli bedzie wiecej takich pakietow (z niektorymi jeszcze walcze/bede
walczyl) dam znac.
python-flac.spec:AC-branch
M.
___
pld-devel-en
Does HEAD version build on Ac?
Hm. I didn't noticed newer version on HEAD. Yes, it has built ok on my
test machine.
M.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
EN:
There are high chances that Ac main tree will be locked before end of
march. Because of that:
1. If anyone wants anything to be included in Ac stable he has to
prepare it on AC-branch (ASAP), check it by sending to test (anyone is
allowed to do that AFAIR) and ask me or someone other with
hawk has reenabled broken utf8 patch. Please fix the patches on
AC-branch and rebuild package or disable this 'feature'.
I didn't enabled utf8 patch in mc. Where do you see it enabled? On AC-branch its
been disabled for a long time.
M.
___
BTW - maybe someone would like to mail again to pine-developers and gain
license for distribution...? Of course, if the patches are ok (on my utf
console it works perfect :) ).
We are allowed to distribute pine with all versions of PLD with patches that
were accepted. Check license file for
It doesn't work correctly here with php 5.2. Sometimes it does stupid things
breaking php code.
It works for me, but on very small site (10 php services).
M.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
Hello.
PLD 2.0 (Ac) main package tree has been permanently locked and marked as stable.
In next few days SPECS SOURCES in CVS will be tagged with AC-STABLE tag.
Packages will be probably signed too. Then I'll start working on iso images
which should be available in two or three weeks.
M.
Hello.
EN:
Since Ac has reached stable state we now need to maintain it for some
time. That means we need... ok, I need more than 5+ people working on
AC-branch. Unfortunately I'll not pay you for your work :(
To make maintaining a bit easier UTF specs will be allowed on AC-branch
and in
Author: hawk Date: Sat Jun 9 07:39:17 2007 GMT
Module: SPECS Tag: AC-branch
Log message:
- updated to 2.6.21.4
Files affected:
SPECS:
kernel-vanilla.spec (1.43.2.4 - 1.43.2.5)
errr??
why updating AC-branch?
why not
vanilla means unmodified. And you are changing that kernel. Doesn't
matter if it's cosmetics or not. No matter if it's patch or sed.
Yes. I know all that. By my previous mail I was trying to say: then it
was never vanilla kernel as sed was used to modify makefile since the
first revision.
M.
Author: glen Date: Tue Jun 19 11:12:32 2007 GMT
Module: SOURCES Tag: AC-branch
Log message:
- update to poldek-0.20.1-cvs20070618.11
Snapshot on AC-branch? I hope you've good reasons like security fixes :)
M.
where should i commit it then? it's USABLE for AC, as it fixes (hopefully
when
more tested) long-lasting pain on multiarch, making total pita upgrading
packages on those arches.
Snapshots have bad habbit of making things not working :/ As I see it few
threads above those snapshots still
EN:
Hello,
I'm looking for full mirror of PLD 2.0 which wasn't updated after June 20th. I
need to restore ac-updates indexes (the were deleted). If any one has such
mirror (official ones have already resynced) please disable its synchronization
and mail me ASAP.
P.S. Partial mirrors are welcome
EN:
ac-supported indexes got smoked too :(
ac-updates i686 will be soon restored to state from June 13th. If you wasn't
updating your poldek indexes after that day you are lucky. Other people will
need to do --upa. If you had bad luck and updated your indexes today or
yesterday you have to do
EN:
Short backstory: between June 18th and June 21st all Ac poldek indexes
for following trees: updates, supported, ready and test were deleted
(instead of being updated) and regenerated from scratch using snapshot
of poldek 0.21. Unfortunately these new indexes were somehow broken
because both
EN:
Correction. Full indexes of ac-updates for i686 have been recovered.
PL:
Poprawka. Pelne indeksy ac-updates dla i686 zostaly odtworzone.
M.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
hey
please bring down this secondary *outdated* ac-amd64 builder whoever put it
online or *fix* it!
The old amd64 builder is not running. Builder account on previous
machine is empty. At least I was told so. We have third amd64 builder? :)
M.
___
maybe a separate list (pld-logs-ti?) should be set up?
Or I may simply remove list address from builder configs for now. There
may be quite big traffic there in next two months or so.
M.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
I think Debian does allow it, but I don't even remember those package
names. BTW: iceweasel.spec contains obsolete version of package, with
well known security bugs.
Those Debian patches seems to simply replace logos and some texts in
source. After removing debian specific chunks from patches
So is this some kind of policy, to require newest packages possible at
the time of upping spec?
It seems so. Its stupid IMO to bump version to highest possible ignoring
real requirements. For example many specs from HEAD are building
perfectly on Ac after dropping unecessary version
It's used to ensure that there are latest packages on the builders. That's
the
only reason I know.
I always thought its RM job to maintain builders. But what do I know... :)
M.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
Not only RM has rights to send packages to builders.
I don't get it. If someone will send some package it will be
automagically upgraded on builders. If such upgrade will fail on deps
I'll usually know about it quite soon and will have to fix it manually
anyway. If someone will send something
The only good thing from bumping version I see is that when upgrade on
builders will fail user will be unable to build dependant stuff till
I'll fix it.
It happens from time to time and this is exactly the problem I was referring
to. (and user can fix the problem himself and resend)
User sends request for: libcrap, few seconds later for appX appY. libcrap
installes fine on i386 but not i686. appX and appY on i386 rebuilds fine with
new libcrap and with old libcrap on i686. Whoops.
True, but only difference is that RM will have to delete appX and appY
for i686 and user
90 matches
Mail list logo
