* Package name : pthsem Version : 2.0.7 Upstream Author : Martin Koegler <mkoegler@auto.tuwien.ac.at> * URL : http://www.auto.tuwien.ac.at/~mkoegler/index.php * License : GPL Programming Lang: C Description : pth replacement with semaphore support This package provides GNU Portable Threads enhanced with semaphore support. . Pth is a very portable POSIX/ANSI-C based library for Unix platforms which provides non-preemptive priority-based scheduling for multiple threads of execution (aka ``multithreading'') inside event-driven applications. All threads run in the same address space of the server application, but each thread has it's own individual program-counter, run-time stack, signal mask and errno variable.
Samuel Thibault <sthibault@debian.org> wrote: * 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
Martin Koegler, le Tue 19 Jan 2010 09:27:07 +0100, a écrit : 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
[..] 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
Samuel Thibault wrote: [...] ...which is usually done by writing to <maintainers@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).
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. 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
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?)
Martin Koegler wrote:
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 <maintainers@gnu.org> to
avoid this unpleasant scenario.)
[1] The gnu-standards package in Debian (both documents available also
online at http://gnu.org/prep).
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 maintainers@gnu.org. I'll keep the list updated about the progress.
Marc Leeman wrote: 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. 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. Thanks!
retitle 565675 RFP: pthsem -- pth replacement with semaphore support noowner 565675 thanks Hi, This is an automatic email to change the status of pthsem back from ITP (Intent to Package) to RFP (Request for Package), because this bug hasn't seen any activity during the last 6 months. If you are still interested in adopting pthsem, please send a mail to <control@bugs.debian.org> with: retitle 565675 ITP: pthsem -- pth replacement with semaphore support owner 565675 ! thanks However, it is not recommended to keep ITP for a long time without acting on the package, as it might cause other prospective maintainers to refrain from packaging that software. It is also a good idea to document your progress on this ITP from time to time, by mailing <565675@bugs.debian.org>. Thank you for your interest in Debian,
retitle 565675 RFP: pthsem -- pth replacement with semaphore support noowner 565675 tag 565675 - pending thanks Hi, This is an automatic email to change the status of pthsem back from ITP (Intent to Package) to RFP (Request for Package), because this bug hasn't seen any activity during the last 12 months. If you are still interested in adopting pthsem, please send a mail to <control@bugs.debian.org> with: retitle 565675 ITP: pthsem -- pth replacement with semaphore support owner 565675 ! thanks However, it is not recommended to keep ITP for a long time without acting on the package, as it might cause other prospective maintainers to refrain from packaging that software. It is also a good idea to document your progress on this ITP from time to time, by mailing <565675@bugs.debian.org>. Thank you for your interest in Debian,
Laba diena, Noriu Jus informuoti apie šių metų pasikeitimą dėl atnaujintos visos Lietuvos įmonių bazės 2018 metų sausio vidurio. Visi juridiniai asmenys pateikti bazėje yra veikiantys, realiai vykdantys veiklą, turintys įdarbintų darbuotojų. Duomenys pagal Sodrą, Registrų centrą. Bazėje nurodoma ir apyvarta, darbuotojų atlyginimai, darbuotojų skaičius, transporto skaičius ir daug kitų duomenų, kuriuos matysite pavyzdyje. Duomenis galima filtruoti pagal veiklas, miestus ir kitus duomenis. Šią bazę verta turėti visoms įmonėms. Pateiksiu priežastis: 1) Kontaktai pateikti bazėje direktorių ir kitų atsakingų asmenų, didelė tikimybė Jums surasti naujų klientų, partnerių, tiekėjų, kai tiesiogiai bendrausite su direktoriais, komercijos vadovais. 2) Konkurentų analizavimas, tiekėjų atsirinkimas pagal Jums reikalingus kriterijus, galite atsifiltruoti pagal įmonės dydį, bazėje nurodoma kiek įmonės skolingos Sodrai. 3) Lengva, greita ir patogu dirbti su šia baze, elektroninius pašto adresus galite importuoti į elektroninių laiškų siuntimo programas ar sistemas iš kurių siunčiate elektroninius laiškus. Taip pat galite importuoti mobiliųjų telefonų numerius į SMS siuntimo programas. Išsirinkite iš "Veiklų sąrašo" veiklas kurių Jums reikia. ( Sąrašas prisegtas laiške excel faile ) Parašykite, kurias veiklas išsirinkote ir atsiųsime pavyzdį ir pasiūlymą su sąlygomis įmonių bazei įsigyti Pagarbiai, Tadas Giedraitis Tel. nr. +37067881041
According to upstreams website the software is no longer maintained. Thus I am closing this RFP. Thorsten