Re: Bug#565675: ITP: pthsem -- pth replacement with semaphore support
Hello, everyone! On Wed, 20 Jan 2010 23:04:07 +0100, Martin wrote: I have no problem with renaming pthsem into pth, if this is wanted by the community. I don't want to do a hostile takeover of pth. But this needs coordination with the other distributions shipping pth. If one of the big distributions says no and still ships GNU pth, it will only cause confusion. The community is not limited to the distribution's package maintainers, however. The developers of applications, which currently have GNU Pth as a build requirement, would need to decide on whether they would want to migrate to an enhanced library. As a packager one typically doesn't replace a library with a forked one without app authors agreeing with that. I see that Ralf has replied. - In general, whether and how to move from a renamed fork to replacing a project (in order for development to continue in various ways) shall be discussed with the author of the library that is being forked, provided that contact can be established. In this case that happened. At Fedora, GNU Pth has not lead to any problem reports in several years. There are only two customisation patches we carry (one to make pth-config switch between /usr/lib and /usr/lib64 at run-time, and another for inserting -g into the compiler flags). So, there is no reason to replace it. Unless app authors started with switching to a fork. Regards, -- Michael Schwendt mschwe...@fedoraproject.org Fedora release 12 (Constantine) - Linux 2.6.31.12-174.2.3.fc12.i686.PAE loadavg: 0.00 0.00 0.00 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#565675: ITP: pthsem -- pth replacement with semaphore support
On Fri, Jan 22, 2010 at 08:08:03PM +0100, Ralf S. Engelschall wrote: This seems like a Debian related discussion. But as the author of GNU Pth I can at least say that I've never heard of pthsem myself (if I received any email, then, sorry, it seems it was filtered by the anti-spam stuff) and also don't know why GNU Pth is considered unmaintained. First, I happy, that contacting you has (finally) succeed and one of mails reached you. Sure, I've not released any newer versions since 2006, but as long as nobody drops me a note that something is broken there is no requirement for any new releases. I'm using it at least under the latest versions of FreeBSD, Linux and Solaris since years. The functionality of GNU Pth is fully complete (at least to the extend I originally planned at about 2004) since 2006 and version 2.0.x. Yes, pth is stable and working, but probably not feature complete for some people (otherwise there would be no need for forks). Over the last 10 years we have seen half a dozen forks of GNU Pth (for various addon functionalities or whatever), but they were at least never named GNU Pth or just Pth. If the current name of this fork is pthsem, please keep it this way. But please avoid naming it (or its Debian package) just pth. Thanks. Calling it pth was the idea of some people on the debian mailing list to avoid having GNU pth and a extended pth package in the distribution. If pthsem is really fully backward compatible to GNU Pth, then we can even check whether we can include its functionality into GNU Pth, too. Where do I find its latest sources? Is is the one under http://www.auto.tuwien.ac.at/~mkoegler/index.php/pth? The latest sources can be found at: http://bcusdk.git.sourceforge.net/git/gitweb.cgi?p=bcusdk/bcusdk;a=shortlog;h=refs/heads/pthsem/master I'll send you in a private mail more details and hits to the relevant changes. Regards, Martin Kögler -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#565675: ITP: pthsem -- pth replacement with semaphore support
On 20.01.10 23:04, Martin Koegler wrote: On Wed, Jan 20, 2010 at 10:06:21PM +0100, Julien Cristau wrote: On Wed, Jan 20, 2010 at 21:04:30 +0100, Marc Leeman wrote: I need pthsem, so I only want a working version with all features I need. All I care about is that there is an agreement between the Debian community and the upstream developer. Martin is very active in supporting his environment and in that respect I am to inclined to support his decision. Can we conclude that pthsem is a valid branch, worth a seperate package? An alternative for Martin is probably to include/hide pthsem in bcusdk; but that would not be as clean IMHO (ffmpeg anyone?) If pthsem is pth + improvements, and pth is unmaintained both upstream and in Debian, what's the advantage of changing the library/package name? I'm not sure we care if its homepage is at GNU or elsewhere. I have no problem with renaming pthsem into pth, if this is wanted by the community. I don't want to do a hostile takeover of pth. But this needs coordination with the other distributions shipping pth. If one of the big distributions says no and still ships GNU pth, it will only cause confusion. I will not call the result GNU pth, only pth. Calling it GNU will probably only add restrictions/requirements, without any benefit. This seems like a Debian related discussion. But as the author of GNU Pth I can at least say that I've never heard of pthsem myself (if I received any email, then, sorry, it seems it was filtered by the anti-spam stuff) and also don't know why GNU Pth is considered unmaintained. Sure, I've not released any newer versions since 2006, but as long as nobody drops me a note that something is broken there is no requirement for any new releases. I'm using it at least under the latest versions of FreeBSD, Linux and Solaris since years. The functionality of GNU Pth is fully complete (at least to the extend I originally planned at about 2004) since 2006 and version 2.0.x. Over the last 10 years we have seen half a dozen forks of GNU Pth (for various addon functionalities or whatever), but they were at least never named GNU Pth or just Pth. If the current name of this fork is pthsem, please keep it this way. But please avoid naming it (or its Debian package) just pth. Thanks. If pthsem is really fully backward compatible to GNU Pth, then we can even check whether we can include its functionality into GNU Pth, too. Where do I find its latest sources? Is is the one under http://www.auto.tuwien.ac.at/~mkoegler/index.php/pth? Ralf S. Engelschall r...@engelschall.com www.engelschall.com -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#565675: ITP: pthsem -- pth replacement with semaphore support
Martin Koegler wrote: I must admit, that I have not read anything about GNU maintainers, but GNU has usually a bigger philosophical overhead. Then I suggest you to read the appropriate documenation [1] before jumping to premature and possibly incorrect conclusions (what does the phrase philosophical overhead entail?). A fork is done when there is some kind of unresolvable conflict/disagreement (be it technical or not). Forking is a fundamental right, so there's nothing wrong in forking pth. But there are too many (forked) packages in Debian, and the Debian QA team would have to maintain the original pth package for some time at least, which is a burden. If there are people actively working to enhance pth, the best (for GNU, Debian, and literally everyone else) is to take over the package upstream. (OTOH, speaking generally, it is sad to see a package reborn under another name just because the prospective new maintainer cannot communicate successfully with the original one to negotiate the takeover. I once again urge you to write to maintain...@gnu.org to avoid this unpleasant scenario.) [1] The gnu-standards package in Debian (both documents available also online at http://gnu.org/prep). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [gmail] Re: Bug#565675: ITP: pthsem -- pth replacement with semaphore support
(OTOH, speaking generally, it is sad to see a package reborn under another name just because the prospective new maintainer cannot communicate successfully with the original one to negotiate the takeover. I once again urge you to write to maintain...@gnu.org to avoid this unpleasant scenario.) Don't read to much into this; pth is for sure a smaller effort in Martins' work. We just want to get over this small hurdle in order to get his really interesting stuff included (which depends on this). OK, sent a short note to maintain...@gnu.org. I'll keep the list updated about the progress. -- greetz, marc Kleeneness is next to Godelness. crichton 2.6.26 #1 PREEMPT Tue Jul 29 21:17:59 CDT 2008 GNU/Linux signature.asc Description: Digital signature
Re: Bug#565675: ITP: pthsem -- pth replacement with semaphore support
Marc Leeman wrote: (OTOH, speaking generally, it is sad to see a package reborn under another name just because Don't read to much into this; Well, as a matter of fact I don't. Probably I wouldn't have replied to the thread if pth wasn't a GNU package, but my opinion would be the same. A fork should be the last resort, when all efforts to prevent the fork have been tried and failed. The introduction of a forked package in a distro is a separate issue, but it naturally is something not to be taken lightly. pth is for sure a smaller effort in Martins' work. We just want to get over this small hurdle in order to get his really interesting stuff included (which depends on this). Avoiding this small hurdle will result in a much bigger hurdle for every distribution, especially Debian when you take into account the number of packages and supported architectures. Every new package results in extra load on the infrastructure (which is not only machines), possible user confusion, possible and very likely further effort by QA/security/release teams, etc. OK, sent a short note to maintain...@gnu.org. Thanks! -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#565675: ITP: pthsem -- pth replacement with semaphore support
On Tue, Jan 19, 2010 at 10:48:24AM +0100, Samuel Thibault wrote: Martin Koegler, le Tue 19 Jan 2010 09:27:07 +0100, a écrit : Samuel Thibault sthiba...@debian.org wrote: Marc Leeman, le Sun 17 Jan 2010 22:16:17 +0100, a écrit : * Package name: pthsem Mmm, could this perhaps rather be just a patch added to the existing pth package? Else you'll have to share the Debian patches. The situation with GNU pth is: I guessed so, but still. The problem is that people know pth, but they don't know pthsem (yet). It will be a long time before people discover that there is a new interesting pthsem package that basically does the same as pth with quite a few extra features, is not dead etc. Why not just replacing the existing pth package with pthsem to avoid that delay? pth and pthsem can be installed in parallel, as they use different filenames (pth.h+libpth.so* / pthsem.h/libpthsem.so*). Both packages use the same symol names in their libraries. The libpthsem-compat provides/conflicts libpth-dev. It contains stub files for pth.m4, pth.h and pth-config, which redirect to the pthsem files. Software built with libpthsem-compat installed will link against libpthsem. My intention was not to replace pth, but to provide a migration path. Were I Martin Kögler, I'd even just request GNU to become the new maintainer of pth. I must admit, that I have not read anything about GNU maintainers, but GNU has usually a bigger philosophical overhead. I need pthsem, so I only want a working version with all features I need. Regards, Martin Kögler -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [gmail] Re: Bug#565675: ITP: pthsem -- pth replacement with semaphore support
I need pthsem, so I only want a working version with all features I need. All I care about is that there is an agreement between the Debian community and the upstream developer. Martin is very active in supporting his environment and in that respect I am to inclined to support his decision. Can we conclude that pthsem is a valid branch, worth a seperate package? An alternative for Martin is probably to include/hide pthsem in bcusdk; but that would not be as clean IMHO (ffmpeg anyone?) -- greetz, marc Radioactive cats have 18 half-lives. crichton 2.6.26 #1 PREEMPT Tue Jul 29 21:17:59 CDT 2008 GNU/Linux signature.asc Description: Digital signature
Re: [gmail] Re: Bug#565675: ITP: pthsem -- pth replacement with semaphore support
On Mi, Jan 20, 2010 at 21:04:30 (CET), Marc Leeman wrote: An alternative for Martin is probably to include/hide pthsem in bcusdk; but that would not be as clean IMHO (ffmpeg anyone?) I don't get the connection with ffmpeg. please elaborate. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [gmail] Re: Bug#565675: ITP: pthsem -- pth replacement with semaphore support
On Wed, Jan 20, 2010 at 21:04:30 +0100, Marc Leeman wrote: I need pthsem, so I only want a working version with all features I need. All I care about is that there is an agreement between the Debian community and the upstream developer. Martin is very active in supporting his environment and in that respect I am to inclined to support his decision. Can we conclude that pthsem is a valid branch, worth a seperate package? An alternative for Martin is probably to include/hide pthsem in bcusdk; but that would not be as clean IMHO (ffmpeg anyone?) If pthsem is pth + improvements, and pth is unmaintained both upstream and in Debian, what's the advantage of changing the library/package name? I'm not sure we care if its homepage is at GNU or elsewhere. Cheers, Julien -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#565675: ITP: pthsem -- pth replacement with semaphore support
On Wed, Jan 20, 2010 at 10:06:21PM +0100, Julien Cristau wrote: On Wed, Jan 20, 2010 at 21:04:30 +0100, Marc Leeman wrote: I need pthsem, so I only want a working version with all features I need. All I care about is that there is an agreement between the Debian community and the upstream developer. Martin is very active in supporting his environment and in that respect I am to inclined to support his decision. Can we conclude that pthsem is a valid branch, worth a seperate package? An alternative for Martin is probably to include/hide pthsem in bcusdk; but that would not be as clean IMHO (ffmpeg anyone?) If pthsem is pth + improvements, and pth is unmaintained both upstream and in Debian, what's the advantage of changing the library/package name? I'm not sure we care if its homepage is at GNU or elsewhere. I have no problem with renaming pthsem into pth, if this is wanted by the community. I don't want to do a hostile takeover of pth. But this needs coordination with the other distributions shipping pth. If one of the big distributions says no and still ships GNU pth, it will only cause confusion. I will not call the result GNU pth, only pth. Calling it GNU will probably only add restrictions/requirements, without any benefit. Regards, Martin Kögler -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [gmail] Re: Bug#565675: ITP: pthsem -- pth replacement with semaphore support
Julien Cristau, le Wed 20 Jan 2010 22:06:21 +0100, a écrit : I'm not sure we care if its homepage is at GNU or elsewhere. Agreed, thanks free software :) Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#565675: ITP: pthsem -- pth replacement with semaphore support
Martin Koegler, le Wed 20 Jan 2010 23:04:07 +0100, a écrit : On Wed, Jan 20, 2010 at 10:06:21PM +0100, Julien Cristau wrote: On Wed, Jan 20, 2010 at 21:04:30 +0100, Marc Leeman wrote: I need pthsem, so I only want a working version with all features I need. All I care about is that there is an agreement between the Debian community and the upstream developer. Martin is very active in supporting his environment and in that respect I am to inclined to support his decision. Can we conclude that pthsem is a valid branch, worth a seperate package? An alternative for Martin is probably to include/hide pthsem in bcusdk; but that would not be as clean IMHO (ffmpeg anyone?) If pthsem is pth + improvements, and pth is unmaintained both upstream and in Debian, what's the advantage of changing the library/package name? I'm not sure we care if its homepage is at GNU or elsewhere. I have no problem with renaming pthsem into pth, if this is wanted by the community. I don't want to do a hostile takeover of pth. That's why you should discuss with GNU. As said in another post, you can just ask them to say on their website that they do not maintain it any more, and point to your page. But this needs coordination with the other distributions shipping pth. With the link mentioned above, that's no problem. If one of the big distributions says no and still ships GNU pth, it will only cause confusion. Agreed. I will not call the result GNU pth, only pth. Calling it GNU will probably only add restrictions/requirements, without any benefit. Right. People often know pth short anyway. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#565675: ITP: pthsem -- pth replacement with semaphore support
Samuel Thibault sthiba...@debian.org wrote: Marc Leeman, le Sun 17 Jan 2010 22:16:17 +0100, a écrit : * Package name: pthsem Mmm, could this perhaps rather be just a patch added to the existing pth package? Else you'll have to share the Debian patches. The situation with GNU pth is: * pth in debian is orphaned (#543857) * the last upstream relase is from 08-Jun-2006 (2.0.7) * the last release was mainly updating copyright + updating autotool files * I tried to contact upstream (Ralf S. Engelschall), while doing the first versions of semaphore support for pth, but failed to get an answer. * I don't remember an answer from Ralf S. Engelschall on the pth-users list in the last year(s). pthsem up to 2.0.7 is GNU pth with some patches applied (semaphore support, valgrind support and various fixes). As upstream seams to be dead, I decided to fork in the upcoming release. Please look at: http://bcusdk.git.sourceforge.net/git/gitweb.cgi?p=bcusdk/bcusdk;a=shortlog;h=refs/heads/pthsem/master * pthsem is now able to cope with system time changes, if it can use a monotonic clock. * moved to automake based build system * GIT repository does not contain any autotool generated files any more, so they get updated at every checkout. * compat package for building pth applications with pthsem * includes lintian clean debian packaging (derived from the offical debian packages) pthsem is an essential dependency of linknx/eibd, so it tested by its users on various plattforms (x86 and various embedded linux variants). Regards, Martin Kögler -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#565675: ITP: pthsem -- pth replacement with semaphore support
Martin Koegler, le Tue 19 Jan 2010 09:27:07 +0100, a écrit : Samuel Thibault sthiba...@debian.org wrote: Marc Leeman, le Sun 17 Jan 2010 22:16:17 +0100, a écrit : * Package name: pthsem Mmm, could this perhaps rather be just a patch added to the existing pth package? Else you'll have to share the Debian patches. The situation with GNU pth is: I guessed so, but still. The problem is that people know pth, but they don't know pthsem (yet). It will be a long time before people discover that there is a new interesting pthsem package that basically does the same as pth with quite a few extra features, is not dead etc. Why not just replacing the existing pth package with pthsem to avoid that delay? Were I Martin Kögler, I'd even just request GNU to become the new maintainer of pth. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#565675: ITP: pthsem -- pth replacement with semaphore support
On Tue, Jan 19, 2010 at 10:48 AM, Samuel Thibault sthiba...@debian.org wrote: Martin Koegler, le Tue 19 Jan 2010 09:27:07 +0100, a écrit : Samuel Thibault sthiba...@debian.org wrote: Marc Leeman, le Sun 17 Jan 2010 22:16:17 +0100, a écrit : * Package name : pthsem [..] The problem is that people know pth, but they don't know pthsem (yet). It will be a long time before people discover that there is a new interesting pthsem package that basically does the same as pth with quite a few extra features, is not dead etc. Why not just replacing the existing pth package with pthsem to avoid that delay? Why not creating a dummy package pth with only compat mode ? This package will be transationnal and will provide a depend to pthsem Regards Bastien -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#565675: ITP: pthsem -- pth replacement with semaphore support
Samuel Thibault wrote: Martin Koegler, le Tue 19 Jan 2010 09:27:07 +0100, a écrit : Samuel Thibault sthiba...@debian.org wrote: Marc Leeman, le Sun 17 Jan 2010 22:16:17 +0100, a écrit : * Package name: pthsem Mmm, could this perhaps rather be just a patch added to the existing pth package? The situation with GNU pth is: I guessed so, but still. [...] Were I Martin Kögler, I'd even just request GNU to become the new maintainer of pth. ...which is usually done by writing to maintain...@gnu.org. It is counter-productive to start a fork just because GNU pth is unmaintained upstream (it is not an officially orphaned GNU package, AFAICS, but that doesn't matter much if it really is neglected). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#565675: ITP: pthsem -- pth replacement with semaphore support
Marc Leeman, le Sun 17 Jan 2010 22:16:17 +0100, a écrit : * Package name: pthsem Mmm, could this perhaps rather be just a patch added to the existing pth package? Else you'll have to share the Debian patches. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
