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 the
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 the
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 ha
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 inc
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.
_
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
https://g
/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 a
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
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
D
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 b
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 rethinking
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 stuf
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
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 "rp
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 to
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
pld-devel-en@lists.pld-linux.or
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 o
For the record: it was libmagic 4.20 fault. Updating file and libmagic
to 4.21 fixed the problem.
M.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
> Author: glen Date: Thu Nov 8 23:57:55 2007 GMT
> Module: SPECS Tag: AC-branch
> Log message:
> - AC-branch move (browser-plugins v2, autoreq dep updates, spellchecker
> enabked)
>
> Files affected:
> SPECS:
>xulrunner.spec (1.37 ->
> compressing so big file is not nice.
> And ordinary system doesn't need logs that are one year old.
Let me put some thoughts here. There is no way to come up with one
universal logrotate configuration that will satisfy 99% of users both
desktop and server ones. IMO syslog and logrotate should be
>> And I will revert that revert and the cdg will have to decide whether
>> are we following some sensible standards (like understanding how things
>
> +1
>From what I understand spec in question was being generated
automagically. However someone have included some translation or other
fixes in i
> 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 b
> however afaik builders don't use chroot poldek, but some copy.
They use chroot poldek.
> if you mean libtool deps, then those not needed. but were there any packages
> besides poldek using rpm library, as soname deps don't work (it's same for
> 4.4.2 and 4.4.9)
>From what I remember it was p
> 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:
/tmp/B.1fd85a/mysql-5.1.22-root-builder/usr/lib64/mysql/ha_f
[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 (Ac)
> 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 Titani
> 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
http://lists.pld-linux.org/mail
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.
> Already available as kernel-vanilla. Regular kernels have to wait for
> grsec and vserver patches.
Grsec is available already, it will be in PLD Titanium as
kernel-bare-grsecurity in next few days. But yes, kernel.spec must now
wait for vserver patch or someone who will port old one.
M.
_
> 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.
___
pl
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
"
> 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 P
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 fixe
> 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
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 scrol
> 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 han
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
pld-d
> +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 mailin
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)
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
> 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, kern
> 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 poldek/
>> 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 b
> 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 cha
> "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 onl
> 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 rhea.p
> 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 rhea.
> 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
http://lists.pld-linux.
> 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
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 som
> 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
> 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
htt
> 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
> 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.
_
> 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
> And bump epoch? Oh boy...
No need to. 1.1.0 wasn't built for Titanium yet.
> how 'bout Ti-branch then?
Aww, it sucks :) "Titanium" is default branch name for, ehm, Titanium :)
> You could have 1.0.0
> in Ti, and once 1.1.x becomes stable, you would just bump version, no
> epoch bymp needed.
> Rejecting devel versions just because they are devel versions is no
> good either
True. There are some devel versions in Titanium :)
> - it's like... should we drop mutt-1.5 from HEAD? Or
> kde*branch 3.5.x diffs?
>
> As I said - it's just a matter of common sense.
I just don't like version
> 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
pld-devel-en@lists.pld-
> 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 ev
> 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
n
> ???
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
> 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 autom
> 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.1&r2=1.2
M.
___
pld-devel-en mailing list
pld-devel-en@li
> and asking again, how the F*K you're supposed to remove the -kb???
Same way you are adding it? I mean, cvs remove it and then cvs add it
again w/o -kb. And yes, you can add -kb without removing the file (via
cvs admin), but _it won't work_ as CR/LF will still be blindly translated.
> until no
> 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
> * 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 x
> Yes, and get to maintain two systems instead of one ;)
Not a problem for me :)
>> Why not just build pae kernels like I do in Titanium for i686? Does it
>> have to be "kernel" instead of "kernel-pae"?
>
> I'm fine with that if there's at least nvidia module available.
All additional kernel st
> 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
> 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
> 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
> hawk: tell your internörs to reconsider trashing the HEAD, kernel.spec's are
> in branches, why can't this be, this is no longer a simple change.
>
> to shadzik: do not remove cc: when replying even if you post gets rejected.
I don't think about it as trashing the HEAD. Being able to use same
> 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
>> 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 -ENO
> 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 stabl
> No, you didn't understand. It's not supposed to be '--with titanium' but
> '--with alternative_option_for_this_package', just like in iceweasel.
It will look kind of funny... --with var_lib_openssl for openssl.spec? I
think I prefer branches then for those few specs and blockers on HEAD.
M.
___
> 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
http://lists.pld-linux.org/mailman/listinfo/pld
>> $Log$
>> +Revision 2.163 2010/02/25 13:18:56 hawk
>> +- force sync scan for scsi_mod in Titanium instead of using hack
>
> why this fix is not ok for other distros like th?
It completly disables scsi async scan at bootup which is enabled in all
our kernels. Thus by including this fix in all
> 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 net
> 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
>
> ?
> 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
http://lists.pl
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
pld-devel-en@l
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 m
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 differ
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:
http://git.tld-linux.org/?p=pld-builder.new.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 rea
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 lis
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
re
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 maili
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
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 scr
Sorry this is half a question half a rant. I'm a bit frustrated with
half a dozen systems to replace.
I think current PLD status is somehow similar to TLD status. Number of
active developers is limited to few persons and they now
develop/maintain system for their own needs, not for other users
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.
___
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:
2014
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.
___
I think the second option is the simplest one, so I would like to
implement it in PLD, unless someone has preference.
Personally I'm using dracut with host-only option enabled. It uses
system wide module blacklist and includes only modules for supported
hardware in initramfs, not all of them.
1 - 100 of 115 matches
Mail list logo
