Re: Looking for contact with Daniel Veillard libxml2 maintainer
On Tue, Jan 16, 2018 at 02:27:15PM +, Tomasz Kłoczko wrote: > On 16 January 2018 at 14:14, Daniel Veillard <veill...@redhat.com> wrote: > > On Tue, Jan 16, 2018 at 01:33:28PM +, Tomasz Kłoczko wrote: > >> Hi, > >> > >> I'm trying to follow procedure described on > >> https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers > >> > >> Daniel seems is not responding for quite long time. > > > > Really ? > > > >> In case of the tickets which I've created it is almost 3 weeks. > >> However I see in git unreplied pull request for more than 3 months. > >> Looks like maintainer is unresponsive. > > > > If you meam w.r.t. Fedora packaging then I would agree, > > if you mean for upstream, well ... no > > Good to see that you are alive ;) > > https://src.fedoraproject.org/rpms/libxml2/pull-requests Page not found (404) With the message: The requested URL was not found on the server. If you entered the URL manually please check your spelling and try again. > https://bugzilla.redhat.com/show_bug.cgi?id=1529121 I think you should find a new maintainer for libxml2, and libxslt, and xmlsec1 because right now I have little time, and since Fedora changes the rules for spec file all the time, they are not interoperable with RHEL/CentOS so the net benefit of maintaining them becomes very low. thanks, Daniel > kloczek > -- > Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH -- Daniel Veillard | Red Hat Developers Tools http://developer.redhat.com/ veill...@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Looking for contact with Daniel Veillard libxml2 maintainer
On Tue, Jan 16, 2018 at 01:33:28PM +, Tomasz Kłoczko wrote: > Hi, > > I'm trying to follow procedure described on > https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers > > Daniel seems is not responding for quite long time. Really ? > In case of the tickets which I've created it is almost 3 weeks. > However I see in git unreplied pull request for more than 3 months. > Looks like maintainer is unresponsive. If you meam w.r.t. Fedora packaging then I would agree, if you mean for upstream, well ... no Daniel > kloczek > -- > Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH -- Daniel Veillard | Red Hat Developers Tools http://developer.redhat.com/ veill...@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F20 Self Contained Change: Apache OpenOffice
On Wed, Jul 17, 2013 at 12:54:10PM +0200, Jaroslav Reznik wrote: = Proposed Self Contained Change: Apache OpenOffice = https://fedoraproject.org/wiki/Changes/ApacheOpenOffice Change owner(s): Andrea Pescetti pesce...@apache.org Add Apache OpenOffice [1], the free productivity suite, to Fedora. == Detailed description == Apache OpenOffice (formerly OpenOffice.org) is an extremely popular free and open- source office software suite. Donated by Oracle to the Apache Software Foundation in 2011, it is now developed and supported by a thriving community; it graduated from the Apache Incubator in October 2012 and it is now an Apache Top-Level Project. Apache OpenOffice 4.0, due in the last decade of July 2013, is a major update. The two new versions (3.4.0 and 3.4.1) released in 2012 under the Apache guidance totalled 60 million downloads so far, not counting mirrors. To be clear, this proposal is about merely adding Apache OpenOffice: it doesn't affect existing office suites included in Fedora and it doesn't require that Apache OpenOffice is made the default office suite in Fedora. == Scope == Proposal owners: Packaging is the main issue here. The default OpenOffice build process produces RPM packages, but there are major changes to be done to obtain a set of RPM packages and matching SRPMs suitable for inclusion in Fedora. One of my specific request therew is make sure that they link to the system libraries instead of relying on the embedded version used e.g. for Windows build. Very specifically make sure libxml2 etc... is not provided by static version inside but uses the system one (so we don't have to push Apache OpenOffice too if there is a libxml2 security errata !) Daniel -- Daniel Veillard | Open Source and Standards, Red Hat veill...@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: twinkle: Intent to retire
On Tue, Mar 12, 2013 at 08:36:57AM +0100, Jan Kratochvil wrote: On Tue, 12 Mar 2013 02:03:16 +0100, Jared K. Smith wrote: On Mon, Mar 11, 2013 at 7:02 PM, Richard W.M. Jones rjo...@redhat.com wrote: Has Fedora *ever* had a functional soft-phone? I ask this because I have tried many, and none of them *ever* worked [...] I've successfully used Twinkle for the last three or four years, Using SIP since 2005 as mostly the only phone and Twinkle was always the only one that worked, despite I tried many. I never wanted to use Twinkle due to its ugly GUI but Twinkle just always worked. I have switched from twinkle to linphone about one year ago, the reason were the crash on twinkle. linphone just works in my experience. Of course I have used ekiga in the past but it wasn't too happy with Cicso hardware. If we loose twinkle we will still have those two, Daniel -- Daniel Veillard | Open Source and Standards, Red Hat veill...@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Static Analysis: proposed interchange format (firehose)
On Wed, Jan 16, 2013 at 03:53:56PM -0500, David Malcolm wrote: This is a followup to my proposal in http://lists.fedoraproject.org/pipermail/devel/2012-December/175232.html I want a common output format for static analysis tools so that we can easily slurp the results from different tools into a database and have a common system for managing the results (marking false positives, having automated de-duplication, etc). (I like the name firehose for the overall system since it describes the issue we'll have of managing the flood of data). I came up with an XML format, which I've uploaded code to here: https://github.com/fedora-static-analysis/firehose Does this look sane? I think that it should be possible to write okay, taking the question from the XML side, so analysing the firehose.rng schemas driving the format. Points and remarks as i go through it: - the cwe attribute is a number or free form ? if a number add and explicit rule to check its type. - the sut content choice is a bit weird on one side you have text on the other you have rpm, I would still allow a free form description but in an element at the same level of rpm something like choice element name=description text/ /element element name=rpm ... element For the sake of larger usage, i would also make some room for debian, and also expand that to be able to express a given file to give an example allowing extra details there, and make some if not all of the attributes optionals, for example to be able to express independance say on the arch: sut file/usr/bin/xmllint/file package type=rpm name=libxml2 version=2.9.0 release=1.fc17 /sut so optional file element, extra type attribute, use package to not feel tied to rpm, but use a type attribute to distinguish :-) - for notes i would separate them notes note.../note note.../note /notes since they are likely to me entered manually, and you may want to track who entered them as you go. - I would use where instead of point myself but i understand your logic too Long reply but overall that look mostly fine from my very narrow POV Daniel -- Daniel Veillard | Open Source and Standards, Red Hat veill...@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
On Fri, Jan 11, 2013 at 01:35:46PM +0100, Michael Scherer wrote: Le vendredi 11 janvier 2013 à 11:24 +0100, Nicolas Mailhot a écrit : Le Jeu 10 janvier 2013 23:33, Bill Nottingham a écrit : - packagereqtelnet/packagereq Nowadays it's commonly used to test if a port is open, not to log in remotely somewhere. What will replace it in this role? why not bash :) $ cat /dev/tcp/localhost/22 SSH-2.0-OpenSSH_6.1 But for remote $ telnet damn-web_server 80 GET / HTTP/1.0 in any case, we can keep it, but moving it out of the standard group definitely makes sense ! Daniel -- Daniel Veillard | Open Source and Standards, Red Hat veill...@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd requires HTTP server and serves QR codes
On Wed, Oct 10, 2012 at 08:43:22AM -0400, Matthew Miller wrote: On Wed, Oct 10, 2012 at 07:17:58PM +0800, Daniel Veillard wrote: libxml2 takes up 5.2M, of which 3.8M is docs It really should go in -devel, I agree ! Check it out -- we've accomplished something with this thread. :) Done, fixed in rawhide, base package install size is now down to 1.6 MB, the docs were already in the -devel package so I kept them there. Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: minimal install set tuning [was Re: systemd requires HTTP server and serves QR codes]
On Wed, Oct 10, 2012 at 08:16:49AM -0500, Michael Cronenworth wrote: Alexander Larsson wrote: Honestly, we should be building glib2 with --disable-fam, since glib will prefer the inotify notification module anyway (it has prio 20 and fam prio 10). It looks[1] like Matthias was watching this thread. Yay! [1] http://pkgs.fedoraproject.org/cgit/glib2.git/commit/?id=3d798c3fdcbab4255323c570fcfc0090bd2980df Let's celebrate one less use of gamin ! Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd requires HTTP server and serves QR codes
On Tue, Oct 09, 2012 at 09:45:09PM -0400, Matthew Miller wrote: On Tue, Oct 09, 2012 at 06:14:39PM -0700, Jesse Keating wrote: Anaconda isn't going to do that unless there is rpm support to re-docify yourself. To accomplish this right now, every package would have to split out a -docs subpackage with all the docs in it. Anaconda /might/ do what you want in the future, by way of kickstart commands, but that's not something we're going to expose in the UI. I was hoping that there might be a few packages we could target to split out the docs from to get us most of the way there, but it really just adds up. There are a few that might be quick but very small wins, though: libxml2 takes up 5.2M, of which 3.8M is docs It really should go in -devel, I agree ! I'll file bugs against these. Much less work than anything else I've seen here, and gets us something -- particularly libxml2, where it's mostly developer docs. no disagreement. Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: request: remove gd.tuwien.ac.at from mirror-lists
On Wed, Oct 03, 2012 at 10:23:48AM -0400, Zdenek Pavlas wrote: On Wed Sep 26 08:02:05, Reindl Harald wrote: yes, and that is why statistics of mirrors are meaningsless because of this fact my idea to give us a config-option dear yum, if the selected mirror provides lower than 500 KB/sek try another one because my line can 12 MB/sec FWIW, we've increased the low speed limit in urlgrabber from 1 to 1000 B/sec. This should fix the most pathological cases. When speed falls below this limit for 30s, download is aborted as if it timed out, and next mirror is used. Each timeout also halves the mirror's estimated speed so it will very likely be avoided next time. https://admin.fedoraproject.org/updates/FEDORA-2012-14928/python-urlgrabber-3.9.1-21.fc18 Cool, thanks ! Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Yum broken behaviour on slow server [was: request: remove gd.tuwien.ac.at from mirror-lists]
On Tue, Sep 25, 2012 at 05:14:58PM -0700, Adam Williamson wrote: On Tue, 2012-09-25 at 10:34 -0600, Kevin Fenzi wrote: On Tue, 25 Sep 2012 13:54:34 +0200 Reindl Harald h.rei...@thelounge.net wrote: since some weeks gd.tuwien.ac.at is creeping around 2-30 KB/second and i am sitting on 100 MBit WAN currently 68 BYTE per second on a test-vm since yum does no longer support switching a mirror with STRG+C https://bugzilla.redhat.com/show_bug.cgi?id=860181 this such mirrors should be removed or yum become a setting that mirrors where a download creeps for longer than 10 seconds below a user configured value taht it will be skipped Well, the thing is that it may be slow from where you are, but is fast for many others. ;( I think some of Harald's other suggestions in the mail are pretty good, though. It does seem like yum could try harder to throw out slow mirrors. It is a bit annoying when you're sitting on a 50Mb/sec connection getting about 200Kb/sec from some sclerotic mirror... To be honnest the above behaviour happens extremely frequently here but with various mirrors, I'm in china and connections are not managed nicely by ISPs and server (don't tell me to switch ISP, there is only 2 available I tested both !). So the server may burst at 100KB/s and be suddenly throttled down to a few bytes per second. For fun while trying this email i just did a yum update -y libxml2 right now I'm seeing: updates/primary_db0% [=- ] 1.3 kB/s | 605 kB 69:11 ETA Sure I'm just gonna wait one hour to see if there is an update available to my package ! The potential user base for Fedora in china is huge, but ATM I perfectly understand why no one would ever want to use it, it's very hard to update our OS unless tweaking the timing database and playing continuously with the available server list :-( Time to write the couple above sentence and now it's updates/primary_db0% [=== ] 158 B/s | 1.1 MB 536:51 ETA you really expect to wait for the completion of the download to mark that server as unsuitable and switch to another one as indicated in https://bugzilla.redhat.com/show_bug.cgi?id=860181#c3 And yes whether it's a single download or multiple one, the time to complete yum is at least the longuest download. If you see that a download is gonna take 20mn cancel it and switch to another server if there is one available ! If you think the code is more intelligent than the user, then make sure the code behave intelligently in all situations. Heh it improved it's only 2 hours to fetch primary_db now, how great ! updates/primary_db0% [=- ] 471 B/s | 2.2 MB 138:40 ETA needless to say, I'm cancelling the command the 0% is only moderately funny BTW. [root@thinkpad ~]# rpm -q yum yum-3.4.3-29.fc17.noarch Daniel P.S.: it's the morning, i.e. the network is not loaded compared to the evening. -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: request: remove gd.tuwien.ac.at from mirror-lists
On Tue, Sep 25, 2012 at 05:14:58PM -0700, Adam Williamson wrote: On Tue, 2012-09-25 at 10:34 -0600, Kevin Fenzi wrote: [...] I think some of Harald's other suggestions in the mail are pretty good, though. It does seem like yum could try harder to throw out slow mirrors. It is a bit annoying when you're sitting on a 50Mb/sec connection getting about 200Kb/sec from some sclerotic mirror... So just imagine when you have 4Mbps and getting not even half a kbps from the server and unable to even kill that update because if you do the damn thing will restart from scratch from the same server and at the same speed. That's the current situation here ! 200Kb/sec is very fast compared to what yum serves us, there are server that fast but yum will stick indefinitely with slow servers. And a fast server today will be a slow one tomorrow depending on the ISP own evaluation of the traffic pattern. Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Heads up, small incompatibility with upcoming libxml2-2.9.0
Hello everybody, I just made a build in Rawhide of libxml2-2.9.0-0rc1.fc19, the first release candidate for the upcoming libxml2-2.9.0 release, I'm targetting a final release beginning of September. This release introduce a small API incompatibility which may affect a few package, among others libxslt, php, python-lxml, gcc libjava and evolution-data-server, all of which should have the patches needed upstream already. More information may be found in the libxml2 and GNOME mailing-lists, basically a structure which used to be exposed at the API level is now opaque for refactoring. That change was made mosly for security reasons: https://mail.gnome.org/archives/xml/2012-August/msg5.html https://mail.gnome.org/archives/desktop-devel-list/2012-August/msg7.html Out of the hundreds of packages relying on libxml2 I expect only a few more who might be affected by the change, this can show up at compilation time with an error about accessing an undefined buf structure. Grab me I will be more than happy to help fixing the problem and getting the patch ready for upstream ! The ABI emulation should work fine at this point, I have been running my Fedora 17 with the updated package without noticing any problem for nearly a week now, even libxslt/xsltproc which probably push the limits of libxml2 APIs works fine, so I'm relatively confident on the current state. One thing I'm unclear about is the best way to get this into Fedora 18, should I try to push the release candidate now to find out which packages need fixing at the code level if we do other mass rebuilds before GA, or should I wait until 2.9.0 is out in a few weeks, possibly relying on the binary compatibility if the affected packages are not rebuilt, Any opinion on the best way ? Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning dnsmasq
On Mon, Aug 22, 2011 at 03:33:58PM -0400, Douglas Landgraf wrote: Hello Stephen, On 08/22/2011 01:49 PM, Stephen Gallagher wrote: (Sent on behalf of jima, the former owner) The dnsmasq package in Fedora has now been orphaned. This package is in need of a new maintainer and should not be allowed to lapse, as it is a critical component of the virtualization features. It is used by libvirt to manage DNS/dhcp for client VMs hosted on a machine, and as such is a mandatory piece of the virtualization puzzle. It would probably then be best if one of the libvirt developers took ownership. I took. Thanks, I certainly watch the package, but I'm happy to delegate this :-) Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v2] Retiring packages in F-16
On Tue, Jul 12, 2011 at 05:10:01PM -0400, Bill Nottingham wrote: Each release, before branching, we block currently orphaned packages. It's that time again for Fedora 16. New this go-round is that we are also blocking packages that have failed to build since before Fedora 14. The following packages are currently orphaned, or fail to build. If you have a need for one of these packages, please pick them up. This list has been fixed to properly show all orphaned packages. It's a lot longer. [...] Orphan libcmpiutil comaintained by: veillard [...] Orphan libvirt-cim comaintained by: veillard I sent a mail to this very list one week ago: Date: Wed, 6 Jul 2011 09:07:57 +0800 From: Daniel Veillard veill...@redhat.com To: devel@lists.fedoraproject.org Subject: Taking ownership of libcmpiutil and libvirt-cim to avoid them being retired, never got an answer. At the time visiting https://admin.fedoraproject.org/pkgdb/acls/name/libcmpiutil didn't show any option to take ownership, was that a temporary failure, I'm sure I checked and was logged in, weird ... Anyway I now took ownership of both. BTW could someone could take care of rel-eng request #4805 http://fedorahosted.org/rel-eng I'm unable to build a recent libvirt-cim for F15 due to the libcmpi update dependancy, thanks in advance ! Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v2] Retiring packages in F-16
On Wed, Jul 13, 2011 at 09:26:25AM -0700, Toshio Kuratomi wrote: On Wed, Jul 13, 2011 at 06:06:37PM +0800, Daniel Veillard wrote: On Tue, Jul 12, 2011 at 05:10:01PM -0400, Bill Nottingham wrote: Each release, before branching, we block currently orphaned packages. It's that time again for Fedora 16. New this go-round is that we are also blocking packages that have failed to build since before Fedora 14. The following packages are currently orphaned, or fail to build. If you have a need for one of these packages, please pick them up. This list has been fixed to properly show all orphaned packages. It's a lot longer. [...] Orphan libcmpiutil comaintained by: veillard [...] Orphan libvirt-cim comaintained by: veillard I sent a mail to this very list one week ago: Date: Wed, 6 Jul 2011 09:07:57 +0800 From: Daniel Veillard veill...@redhat.com To: devel@lists.fedoraproject.org Subject: Taking ownership of libcmpiutil and libvirt-cim to avoid them being retired, never got an answer. At the time visiting https://admin.fedoraproject.org/pkgdb/acls/name/libcmpiutil didn't show any option to take ownership, was that a temporary failure, I'm sure I checked and was logged in, weird ... Sorta. These packages were orphaned due to the maintainer not signing the FPCA. When that script was run, I failed to properly set the status to Orphaned which left you unable to take ownership. Sorry for missing your earlier email about the problem and thanks for taking them now! Ah, okay, there is an explanation, I was a bit puzzled to not see the take ownership button though it was owned by orphan, I was thinking the feature wasn't available anymore. thanks ! Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads-Up: Beware of xmlCleanupParser() when your package links against libxml2
On Wed, Jan 13, 2010 at 04:07:24PM -0500, Tom Lane wrote: Lennart Poettering mzerq...@0pointer.de writes: There's something else that came to my mind: if libxml2 is loaded into memory indirectly because some dlopen'ed module wanted it, and then used, and then unloaded again because the module got dlcose'd again, won't you leak TLS vars unless the xmlCleanupParser() function was called properly before? In that case, not calling xmlCleanupParser() is an error, right? And calling it, too, since some other plugin/thread might still need it. Which means you are in a dilemma: in either case you are doing it wrong. Got it in one. libxml's API in this area is unusably broken, and needs a ground-up redesign not random messages telling users that they didn't use it right --- there *is* no right way to use it. My experience with this comes from the Postgres project, which wasted many moons trying to use xmlMemSetup() ... basically, you can't replace libxml's memory management, you just have to live with whatever it chooses to leak. First time I see something coming from you or Postgres group complaining about a leak or about the use of xmlMemSetup() Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads-Up: Beware of xmlCleanupParser() when your package links against libxml2
On Wed, Jan 13, 2010 at 04:54:34PM -0500, Simo Sorce wrote: On Wed, 13 Jan 2010 22:39:43 +0100 The dilemma is in broken libraries that use global variables instead of explicitly initialized memory contexts so that you can have multiple completely independent instances and also happen to help make them thread safe. I provided a bunch of new parsing API in libxml2 precisely to avoid the problem of global variables, but well unless I make a non-compatible API and hence libxml3 (no target date, probably never) this problem will stay around. Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
