you conveniently cut out the context, this happens when rpm5 installs
the package built by rpm4.16
And it would not happen if packages built by rpm 4.16 will not provide
build-id dirs.
M.
___
pld-devel-en mailing list
On 23-Mar-21 21:51, Elan Ruusamäe wrote:
so, what could be done is fix that rpm4.16 buold will not generate deps
for things unde:
/usr/lib/.build-id/
In TLD I've simply set default of %_build_id_links macro to alldebug so
regular packages are not cluttered with build-id stuff (it all goes
rpmbuild --nobuild doesn't return missing deps, just empty output
This call is used in install.py of pld-builder.new and not returning
missing deps results in builders not doing auto install of missing deps.
M.
P.S. Tested on TLD, but differences shouldn't matter in this case
Looks like
On 11-Jan-21 09:38, Jan Rękorajski wrote:
Hi,
Later this week rpm from rpm.org, along with all necessary tools
(macros, poldek, specdump, etc.) are going to land in th-test.
I believe the last real stopper[1] has been "fixed", so we should finally
switch.
If you think there is still something
On 02-Dec-20 21:06, Elan Ruusamäe wrote:
the current state in pld php packages is because
lazy-ness/lack-of-time/no-interest, and you haven't ported your changes
back :(
I'm not porting back any changes which break "clean" poldek upgrades,
require modification/addition/testing of systemd
On 02-Dec-20 16:08, Jan Rękorajski wrote:
- mutual obsoletes (php* only problem?)
I honestly don't know what to do with this, rpm behavior seems sane to me,
maybe we should rethink how this is packaged (maybe replace with Conflicts
and let administrator deal with it?)
+1 for
Feel free to merge updated ceph from TLD. Or use it as starting point
for your own spec (with systemd support etc.)
https://git.tld-linux.org/?p=packages/ceph.git;a=summary
Note: ceph is now x64 only, x86 is officially not supported anymore.
Also frontend is not being build (downloads "to be
On 23-Jan-20 12:36, Jan Rękorajski wrote:
I want to drop nopae, 4.4 and 4.14 kernels from Th,
leaving us with longterm releases 4.9 (the last kernel that supports vserver),
4.19, 5.4 and a latest stable.
Thoughs? Cons?
4.14 has longest planned support - up to Jan 2024 while 4.19 will EOL on
In ALT, we've moved exactly towards multiple versions so that
people switch (and dump/restore) between them when they know it,
and not after an overlooked line in dist-upgrade's output...
(when it's too late to use the upgraded "dumper" for that)
With multiple versions installed it is easier to
/etc/mail was a bad idea, so such migration in all MTAs and tools is
welcome :)
Except sendmail where /etc/mail seems to be "worldwide" default.
/etc/ftpd is next to go in TLD.
About merging back such changes...
1) I don't use PLD at all so I have no way to test changes in real
environment
diff --git a/rsync.spec b/rsync.spec
index d663909..a257e2d 100644
--- a/rsync.spec
+++ b/rsync.spec
@@ -1,3 +1,4 @@
+# TODO: 3.1.3 rsyncd segfaults very early in server rsync:// mode
(both inetd and standalone)
FYI...
https://www.mail-archive.com/rsync@lists.samba.org/msg32342.html
Any thoughts? Anybody ready to do proper testing for the new package? Or
am I doing this just for sport?
I'll try to test it however tests will be done on TLD, not PLD and I'll
need some time to adjust/rebuild packages and port my 2.2 configs.
M.
i was thinking too, why the include_shell was in place, but did not
bother to look to git history.
digged now, and no obvious reason written. so i guess the glob include
didn't exist at the time
https://github.com/pld-linux/lighttpd/commit/4ea50529e182703e064e0053d13c9e7953f0d201
Yes, glob
On 18-Sep-18 09:23, glen wrote:
the same host, updated
wintersunset /etc/lighttpd # rpm -q glibc lighttpd; ls -l
/etc/lighttpd/vhosts.d/
glibc-2.28-3.x86_64
lighttpd-1.4.50-2.x86_64
total 0
wintersunset /etc/lighttpd #
so it's lighttpd behavior change.
Since 1.4.50 include_shell behavior
looks like 7.2.0 is older than 7.0.5? like 7.2 is development branch for
7.0? huh? and they both result v14 database?
so i'm a bit confused of their releases, and what version series we
should stick in pld?
Its not older. Bacula isn't always providing all SQL migration paths and
scripts in
looks like 7.2.0 is older than 7.0.5? like 7.2 is development branch for
7.0? huh? and they both result v14 database?
so i'm a bit confused of their releases, and what version series we
should stick in pld?
Its not older. Bacula isn't always providing all SQL migration paths and
scripts in
as appears it goes down to these php modules:
Tue Oct 7 15:18:24 2014 php53-pcre-5.3.29-1.i686
Tue Oct 7 15:19:30 2014 php53-session-5.3.29-1.i686
Tue Oct 7 15:19:30 2014 php53-simplexml-5.3.29-1.i686
Tue Oct 7 15:19:30 2014 php53-spl-5.3.29-1.i686
installing or removing these modules (they
Checking Apache 2.4 Web Server configuration...[ DONE ]
Stopping Apache 2.4 Web Server service.[ DONE ]
Starting Apache 2.4 Web Server service.[ FAIL ]
(98)Address already in use: AH00072: make_sock: could not bind to
So... Any chances to get that ACL done? Come on guys, it will take about
30 seconds.
FYI: I got data I needed the other way. I no longer need this rsync
access. Thanks for your prompt response to my request (sarcasm intended).
Note to baggins (or repo admins): you are free to perform further
On 2014-09-23 06:28, Arkadiusz Miśkiewicz wrote:
Isn't rsync freely available to anyone?
rsync rsync://git.pld-linux.org/
We apologize, temporary out of public service.
Ok, I see it is not. I wonder what was/is the problem with it.
So... Any chances to get that ACL done? Come on guys, it
Ok, I see it is not. I wonder what was/is the problem with it.
From what I remember it was always that way. As mentioned I had access
there and I remember adding my hosts to rsync acls when I was keeping
CVS/SVN mirrors years ago.
Unfortunately my ssh keys were removed so I can't check how
Maybe it's because we use git instead of cvs now?
CVS in this case is just hostname and git is just cname to cvs so we are
talking about same host here.
M.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
Do we care? Looks a bit fishy...
Common DNS related spam. I personally ignore these.
M.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
wget -nv --no-check-certificate --user-agent=PLD/distfiles -O
./tmp/338293ab-1349-44bb-9002-ba0ccb8c0c3e/c5f88765e74945f7fa18c3a3141f5334/bios.bin-1.7.4.gz
http://code.coreboot.org/p/seabios/downloads/get/bios.bin-1.7.4.gz:
http://code.coreboot.org/P/seabios/downloads/get/bios.bin-1.7.4.gz:
Any ideas which part of our automation changed p in above URL to
uppercase causing error 404? Using builder or wget manually properly
downloads this file. Any chances for fix or should I just upload it to
distfiles manually?
FYI, uploaded it manually to dropin.
M.
What configuration (compared to default)?
syslog-ng 3.4.3 + libivykis 0.39 works for me, configuration is almost
default.
Maybe significant change: I'm using syslog-ng built --with dynamic.
Trited both, my own config and default one installed by package. It
segfaults on both.
M.
Are there sanely recent CRI images for TH to be had anywhere?
Officially - no. I've recently started developement of completly new
version of CRI which will be used as default installer/rescue for TLD,
but I'll not be including Th chroots anymore unless someone will create
them (including
Hi,
Just a heads up, I'm going to remove/move to obsoleted some packages
fom Th. List and reasons below:
java-sundead and obsolete
Any official note on Java 6 being dead and obsolete? Can't find one on
Oracle site.
module-init-tools replaced by kmod, udev now requires
OpenGL-GLES, OpenGL-ES or OpenGLES?
The standard's name is OpenGL(R) ES...
(see http://www.khronos.org/opengles/ for more information)
I followed naming scheme already used in other specs, ie. OpenGL-GL
instead of just OpenGL.
Also, these packages provide two libraries conforming to
When we were using CVS it was possible to resend tagged package to builders
using package:auto-th-... syntax.
Something changed or some builder functions were not updated for
auto/th/ prefix?
Following change is needed to get it working with git:
Doesn't that make builder do forced retagging (which is not desired here) ?
Yes. It replaces current tag with same name (note: not by delete tag,
re-add tag), but otherwise build will fail because git tag command will
return failure if given tag already exists while cvs was returning ok
and
Hawk has given the solution to the problem. But my question is the
purpose of resending the build from the same tag? I'm assume that it
would a test build, as the ready one would fail due to preexisting tag.
No. Ready build with auto tag shouldn't fail. Lets say someone sends 10
packages as
I have the same fix, but I have not pushed it as I am not 100%
happy with it. It changes the send request send with path/spec:tag
Can you explain? I pretty you mean something different than what I'm
thinking about.
M.
___
pld-devel-en mailing list
What do you mean by shouldn't fell. Script builder will fail if you run
like: builder -bs -Tp auto/th/ -tt .
and the auto tag generated from required revision already exist. It was
the case in CVS, it is the case in git.
It will fail on git, it wasn't failing on CVS due to difference in
Better, but still not the same as previously.
Thats make-request.sh thing and has nothing to do with change we are
talking about right now (added -cf to builder script call to allow ready
builds with auto tags to succeed).
M.
___
pld-devel-en
Are you sure it was it? Because fetchsrc_request in cvs uses different email
for 9 years.
Yes, I'm sure. I've sent this request from my very very old devel
account. Didn't checked what destination mail was defined in it though.
M.
___
pld-devel-en
it's back now
caused by one small mail:
Seems like you'll need to fix distfiles mail handling. It was mail
generated by packages/fetchsrc_request.
M.
P.S. And I must agree with shadzik here. Get a life.
___
pld-devel-en mailing list
On Tue, 12 Oct 2010, lmasko wrote:
+* Add a DEVEL branch (assuming, that the DEVEL tag does not exist):
+
+ builder -B DEVEL name.spec
+ cvs up -r DEVEL name.spec
+ cvs ci name.spec
Just curious: why this is better than just:
cd rpm/packages/name;
cvs tag -b DEVEL
?
Because it tags
cvs tag -b DEVEL with cwd=packages/name will tag all tracked files
in packages/name directory (?)
True. Builder will tag only those actually associated with spec file.
M.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
Is it possible these days to not have udev packages installed at all?
From what I know... no. But I may be totally wrong :-)
I had bunch of machines running with static dev. They were fine with
kernel 2.6.27.x, but stopped working properly with kernel 2.6.32.x. One
was unable to initialize
So what are exact rules at the moment?
What if someone wants to create another branch of distro?
I'd like to know that too. When I've created Titanium I was keeping
separate branches on some specs. That was baad, because I wasn't merging
my changes/updates to HEAD. So I started using %if
Number of specs where %if %{pld_release} macros are used isn't that
big and doesn't make modifying them that hard. I don't ask anyone to
edit/adjust/fix Titanium part of such specs, just forget its there and
focus on Th part.
This is what bconds are for. Their state is the only thing that
I'd like to know that too. When I've created Titanium I was keeping
separate branches on some specs. That was baad, because I wasn't merging
my changes/updates to HEAD.
But that's not our fault, is it? :)
Yes it is. Hawk working on Titanium and not merging his changes because
of -ENOTIME -
Probably I missed some discussion on irc or pld-devel-pl... but what
is exact purpose of Titanium? Why it started in first place?
There are two main reasons:
1. To have stable distro with actual software. Ac had and has too old
software for me and Th is still light years away from being stable
BTW any chances on iceweasel 3.6?
Yes. I'm working on Iceweasel, Icedove and Iceape upgrades, but my time
for PLD is limited right now.
M.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
this will fail by some other dependencies, like vidia and if the binary
checksum is identical rpm will allow installing the same file twice, at least
in multilib case, not sure for same-arch-case how it behaves.
I have multiple kernel*-misc-vbox* on same arch and there were no
conflicts on
Some time ago http://en.wikipedia.org/wiki/PLD_Linux_Distribution was
deleted...
Has anybody some cogency and free time to restore it?
What for? They'll delete it again. The reasons for deletion were:
Since the article quotes only primary sources (same for all
foreign-language versions),
Can somebody tell me who to get in touch with regarding commit access
to PLD spec files?
I requested access back in Nov of 2007 after submitting some patches
and specs. I was +1'd by Aria and Krystian as well as feedback from
Andrzej and Elan. I was then contacted and asked to turn in my
* 4GB is more and more common on consumer grade machines (heck, my
not-so-now custom made laptop has 4GB)
Yet with PAE single process still won't be able to allocate more than
~3.2 gigs of RAM. So if someone really want to use more than 4 gigs of
memory x86_64 is way better choice.
* some
wtf, don't you want to do it opposite way, so that /etc/ migration doesn't
have to be done again in the future?
There will be no migration of /var/lib/openssl to /etc in Titanium. Th
was not affected by my changes.
M.
___
pld-devel-en mailing list
this will make cvsweb unable to provide diffs between versions,
Diffs works just fine with this change on both old and new cvsweb.
however, we shouldn't add msdos files to cvs, undos the sources before
patching instead is better solution.
No no no. I don't want to see dos2unix going
no diffs, no view as text...
Only in new cvsweb that was forced some time ago. Good old one works
just fine:
http://cvs.pld-linux.org/cgi-bin/cvsweb/test/kdeaddons-babelfish-google.patch?r1=1.1r2=1.2
M.
___
pld-devel-en mailing list
???
Just some of my old habits, nothing to worry about.
M.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
my suggestion is to change it to 755,root,root as i don't see much gain other
than security by obscurity
and adding builder user to adm group i don't want to do either. assuming home
dir of 'service' should be /home/services.
I'm happy with current permissions as I don't need to chmod every
and doing chmod on directory from rpm package, will make the permissions lost
again if the owner package is upgraded. this is not consistent behaviour.
This can be prevented with %_netsharedpath. I'm using it ie. for
/var/mail where our distribution default permissions prevent creation of
I'm pretty sure I typed my password correct at least once on about 10
attempts... has anything changed regarding dropin usage recently?
I've logged in on first attempt. Check your keyboard ;-)
M.
___
pld-devel-en mailing list
I don't see why this can't go to Th, especially as there are beta
versions of kde4.
I vote for moving it to DEVEL branch. Why make exception for this spec?
It still can be built from DEVEL for Th test.
If its unacceptable then please branch 1.0 as WINE_STABLE or something
so it may be still
The problem with split is that people using su to switch to root will have a
problem after doing simple upgrade (most people won't notice -su subpackage).
Suggests for -su subpackage? Everyone will be prompted on upgrade to
install it or not.
M.
Anyone knows what happened to them?
ac-amd64 was on oberon.pld-linux.org which was taken down to move from
Warsaw to Poznan. Ask arekm for details. Don't know anything about ac-alpha.
M.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
A wild guess would be: th-i686 does not have kernel-headers installed.
Or kernel-source.
M.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Why would you need kernel-source to build anything?
I don't know, but I remember that I had to install it to build some
kernel related specs. Sadly, I don't remember which specs :(
M.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
check if debian patch update made the badness
Doesn't seems so.
M.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
file 4.24 from HEAD breaks building of both php and php4:
checking whether to include mime_magic support... yes, shared
configure: error: File '/usr/share/file/magic.mime' not found!
error: Bad exit status from /tmp/B.f36187/rpm-tmp.60037 (%build)
Any ideas to fix? Was magic.mime obsoleted by
you're not paying attention what i say. so this is last email in this thread
from me. bye!
And vice versa :) Thanks god I've forked. Keep breaking more stuff.
M.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
Guys, please stop fighting and actually do explain and dive into
details when replying. It could be that you are both right just
approaching the same problem from two different angles. Keep PLD a
healthy place for further flamewars :)
Problem is already fixed, flame is over and next time I'll
before 2.6.24 is also questionable.
Do you mean that we should make triggers to act on something that never
existed in distro, but in CVS only? Its insane idea and if such policy
will occur I'm leaving this train.
it is properly solved in 2.6.22 branch
(so the links appear only and only if
that is still package install stage, not package build time.
there is no such thing as directory deps are added to package. these are
verified at package installation stage.
If its at install stage, not build time then how my private computer
knows exact path to builder chroot ie. on
that is still package install stage, not package build time.
there is no such thing as directory deps are added to package. these are
verified at package installation stage.
If its at install stage, not build time then how my private computer
knows exact path to builder chroot ie. on
so merge in the missing trigger and NOTE that you should package a ghost FILE
not SYMLINK
What missing trigger? There were no such %ghost entries before 2.6.24
and 2.6.24 from LINUX_2_6 branch didn't made it officialy to any version
of PLD yet. This part of my commit is simple revert of
AFAIR there was just few KB left on some disk. Also I don't have
installer build environment anymore.
Pity, but I'll try to make some.
I hardly belive that you will succeed. To get extra space you will need
to remove some kernel modules included on bootdisks. While this can be
done on
I dont understand why making 3 lines of distro (with all the time and
work effort) which almost are identical (or becomes to be)
Just a few thoughts that I wanted to share...
I gave up Ac as some updates/changes were impossible to do or shoudn't
take place in stable distro (glibc, gcc,
hawk did. and the biggest problem was that the data does not fit to disk.
AFAIR there was just few KB left on some disk. Also I don't have
installer build environment anymore.
upgrading disks, would mean that disks should use also packages from
ac-updates, which in turn means the
On 28.03.2008 22:53, glen wrote:
Author: glen Date: Fri Mar 28 21:53:41 2008 GMT
Module: SPECS Tag: AC-branch
Log message:
- merged too much; rel 4
Files affected:
SPECS:
util-vserver.spec (1.138.2.35 - 1.138.2.36)
Why too
On 27.03.2008 13:18, glen wrote:
Author: glen Date: Thu Mar 27 12:18:17 2008 GMT
Module: SPECS Tag: HEAD
Log message:
- force system libtool, which is not broken; rel 2
Files affected:
SPECS:
libntlm.spec (1.17 - 1.18)
Same
error: python-gnome-desktop-apidocs-2.22.0-1: req
/usr/share/gtk-doc/html not found
Should we add this directory to gtk-doc.spec (+1) or to
python-gnome-desktop.spec?
M.
P.S. Titanium, but Th probably has the same.
___
pld-devel-en mailing list
+1 for gtk-doc, I think it already creates the dir but rpm does not
warn about unpackaged empty dirs.
Interesting... This directory is provided by gtk-doc-common. I wonder
why poldek doesn't see it and reports broken dep.
M.
___
pld-devel-en mailing
Hello.
Yesterday I've encountered interesting behaviour on Ac machine. Frst
I've upgraded rpm* and poldek* to latest versions available from Ac.
Then after manual rpm --rebuilddb I've issued poldek --upgrade-dist.
Since system was quite old there were lot of packages and poldek output
was
it could as well be trash created by poldek...
.03]1ac..][3 -- the dots are \033 aka escape? and ac is poldek source name
probably? if this is true it links more to poldek than rpm (rpm doesn't do
any colouring or have any idea what is ac)
The string above was an example typed by hand, not
I'll test it tomorrow. I'll also test initrd with udev and lvm.
I've already commited changes to geninitrd. Now it works properly with
udev inside initrd. Tested with root fs on raid1, lvm2 and lvm2 on top
of raid1.
M.
___
pld-devel-en mailing list
Are modutils installed?
The only thing module-init-tools can do on 2.4.x is to exec modutils
counterpart.
Yes. They're installed.
# rpm -q modutils module-init-tools kernel24-smp
modutils-2.4.27-7.i686
module-init-tools-3.2.2-3.i686
kernel24-smp-2.4.35-1.i686
M.
2. Kernel 2.6.16.60 is broken. On all machines when where I tried to
boot it (including VirtualBox) it just displayed dozens of messages:
Unknown interrupt or fault at EIP 0060 c0100295 0294
and it finally hangs so only cold boot works.
This seems to happen on machines w/o PAE.
I've been playing a bit with udev inside initrd. Currently it doesn't
work at all because after starting 'udevd --daemon' /dev is almost empty
(just basic entries like null, console, etc., no device nodes). This may
be fixed by using PROBESTATICMODULES=yes in geninitrd (just commited
small
Hi.
I was just udpating my Ac chroots used by CRI. There are two very bad
bugs in current Ac (main + updates).
1. module-init-tools (3.2.2-3) has broken modinfo (and probably more
stuff). It doesn't work with 2.4 kernel. Try 'modinfo piix' or any other
module. It will say you something like
So, I demand ;-) nVidia legacy2 driver packages for kernel-laptop :)
Switch to Titanium :) There are 6 kernels there and probably will be
more in future. There are also additional modules built for every
kernel, including nvidia drivers :)
M.
___
what's wrong with big numbers? you're arithmophobic/polyphobic? :)
I can live with them. However I hope not to see
rpm-4.4.9-2.375745848e+12.i686.rpm :)
M.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
Ehh. Looks like bug in poldek. It doesn't find proper requirements by
dependencies. Adding them manually works.
M.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Hi.
There are problems with recent kde No way to install some parts of it
w/o using --nodeps. Few examples below. There are probably more.
Weird things: rpm -qp --requires doesn't show these requirements. Also
poldek --verify=deps doesn't show those problems, yet its impossible
to install.
Author: glen Date: Fri Feb 15 00:42:54 2008 GMT
Module: SPECS Tag: rpm-4_4_9
Log message:
- find-lang moved to rpm-build-maros package; rel 38
Was it really necessary? I was just one small step from branching
rpm-build-macros for Titanium
Author: glen Date: Sun Jan 13 00:53:46 2008 GMT
Module: SPECS Tag: HEAD
Log message:
- re-enable federated; rel 5
Fails to build:
RPM build errors:
File not found by glob:
[EN]
In last few months I wasn't doing too much to keep PLD Ac up to date :(
Most of work including FTP management was done by Elan Ruusamäe. Since
I'm currently working mostly on PLD Titanium I've decide to resign from
RMing Ac. Starting from today Elan Ruusamäe is release manager of PLD
2.0
i've prepared rpm 4.4.9 and poldek for ac
any objections why not push it to ac-updates?
There weren't much problems with rpm 4.4.9 when Titanium was just Ac
with new rpm. Update was a bit tricky but then it worked without problems.
For Titanium to change rpm to 4.4.9 following things had to be
Hello.
While trying to get base PLD Titanium working I've encountered serious
problem with rpm and I can't find what causes it. Any help or hints will
be appreciated. Situation (in chronological order):
1. rpm 4.4.9-1 was built manually in PLD Ac amd64 chroot after hacking
macros to force usage
92 matches
Mail list logo
