Re: Fwd: Cron ~/rpm/PLD-doc/notify-specsupdate.sh
On 25/10/2018 15:21, Adam Gołębiowski wrote: W dniu 2018-10-23 13:01, Arkadiusz Miśkiewicz napisał(a): On 23/10/2018 12:43, glen wrote: any plans to fix cvs.pld-linux.org? cvs-nserver segfaults and needs some debugging or better switching to other maintained cvs cvs [status aborted]: reading from server: Connection reset by peer Had a look at this today, there's some magic happening here: Better switch to cvs.spec as it is maintained by Debian at least and gets security fixes that way. Other cvs servers are not maintained and should be dropped IMO. -- Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org ) ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Fwd: Cron ~/rpm/PLD-doc/notify-specsupdate.sh
W dniu 2018-10-23 13:20, Jacek Konieczny napisał(a): On 2018-10-23 13:01, Arkadiusz Miśkiewicz wrote: On 23/10/2018 12:43, glen wrote: any plans to fix cvs.pld-linux.org? cvs-nserver segfaults and needs some debugging or better switching to other maintained cvs cvs [status aborted]: reading from server: Connection reset by peer Or maybe it is time to finally ditch CVS all together. There is really no good reason we are still using this crap for anything. What do we use cvs for these days? In the last two years there were commits to: - CVSROOT/users - I think it is currently used for aliases only, - PLD-doc: - uid_gid.db.txt - BuildRequires.txt - PLD-update-TODO + maybe SSH-keys So nothing much, really. Am I missing something? -- Adam Gołębiowski, PLD Linux ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Fwd: Cron ~/rpm/PLD-doc/notify-specsupdate.sh
W dniu 2018-10-23 13:01, Arkadiusz Miśkiewicz napisał(a):
On 23/10/2018 12:43, glen wrote:
any plans to fix cvs.pld-linux.org?
cvs-nserver segfaults and needs some debugging or better switching to
other maintained cvs
cvs [status aborted]: reading from server: Connection reset by peer
Had a look at this today, there's some magic happening here:
15:01:13: S -> Loading protocol enum as enum.la
15:01:13: S -> EBUG: name=enum.la
directory=/usr/lib64/cvsnt/protocols
15:01:13: S -> It is ORACLE so save environment.
that nails down the path to
cvsnt-2.5.05.3744/cvsapi/unix/LibraryAccess.cpp:
75 bool CLibraryAccess::Load(const char *name, const char *directory)
76 {
77 if(m_lib)
78 Unload();
79
80 CServerIo::trace(3, "EBUG: name=%s directory=%s", name,
directory);
81 if (strncmp(name,"oracle",6)==0)
82 {
83 /* this is very messy, but the server crashes/hangs
84when the oracle library is unloaded due to the
85putenv ... */
86
87 /* For this kind of thing better to put a load/unload
hook in the
88 library itself, otherwise it just gets too messy
hardcoding
89 everything. */
90
91 CServerIo::trace(3,"It is ORACLE so save
environment.");
92 strcpy(save_nls_lang,getenv("NLS_LANG"));
So it looks like it compares name ("enum.la") to "oracle" and decides
they are equal...
and if I comment this part out, it goes into infinite loop
--
Adam Gołębiowski, PLD Linux
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: glibc and ldconfig dependency loop
On 2018-10-01 16:42, glen wrote: > On 10/1/18 11:36 AM, Jacek Konieczny wrote: >> Possible solutions: >> – disable autogenerated dependency for ldconfig, to force installing it >> before glibc >> – include ldconfig in the main glibc package >> – change glibc %post so it won't fail on ldconfig error. The easiest >> one, will fix the glibc installation failure, but won't break the >> dependency loop. >> >> Any better ideas? > > make ldconfig package skip rtld(GNU_HASH) dependency. > by building (linking?) it it differently; or just do rpm ignore magic? I found another idea and implemented it – I have separated 'ld' package, to provide both the dynamic linker (/lib/ld-*) an the ldconfig tool. This is what contains those cross-dependencies and it does not pull any other dependency that whole glibc package could pull. Currently pushed with 'Release: 6.1', to become 'Release: 7' if there are no objections. Jacek ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
