Bug#1038429: ITP: golang-github-serialx-hashring-dev -- consistent hashing "hashring" implementation in golang
Package: wnpp Severity: wishlist Owner: Carlos Henrique Lima Melara X-Debbugs-Cc: debian-devel@lists.debian.org, debian...@lists.debian.org, charlesmel...@riseup.net * Package name: golang-github-serialx-hashring Version : 0.0~git20190422.8b29126-1 Upstream Author : Sung-jin Hong * URL : https://github.com/serialx/hashring * License : Expat Programming Lang: Go Description : consistent hashing "hashring" implementation in golang Implements consistent hashing that can be used when the number of server nodes can increase or decrease (like in memcached). The hashing ring is built using the same algorithm as libketama. . This is a port of Python hash_ring library in Go with the extra methods to add and remove nodes.
Bug#1038427: ITP: golang-github-serialx-hashring -- Consistent hashing "hashring" implementation in golang
Package: wnpp Severity: wishlist Owner: Carlos Henrique Lima Melara * Package name: golang-github-serialx-hashring Version : 0.0~git20190422.8b29126-1 Upstream Author : Sung-jin Hong * URL : https://github.com/serialx/hashring * License : Expat Programming Lang: Go Description : consistent hashing "hashring" implementation in golang Implements consistent hashing that can be used when the number of server nodes can increase or decrease (like in memcached). The hashing ring is built using the same algorithm as libketama. . This is a port of Python hash_ring library in Go with the extra methods to add and remove nodes.
Re: opencl-icd virtual package(s)?
On Sun, 2023-06-18 at 10:37 +0800, Paul Wise wrote:
> [BCCed to OpenCL ICD implementation package maintainers]
>
> I noticed that some packages have a dep on specific OpenCL ICD
> packages, but don't dep on the opencl-icd virtual package(s).
> Presumably any of the OpenCL ICDs work for most packages?
Theoretically any of them is expected to work. That's the point of ICD.
But, while I'm not an OpenCL user, I have heard that different OpenCL
implementations have their own quirk... (forgotten source)
> $ grep-aptavail --no-field-names --show-field Package --field
> Depends,Recommends,Suggests --whole-pkg '(' --pattern .*opencl-icd.* --
> and --not --pattern '^opencl-icd(-1\.[1]2-1)?$' ')'
>
> In addition, I noticed that hashcat-nvidia (which presumably doesn't
> need to depend on the opencl-icd virtual package) only depends on two
> of the nvidia OpenCL ICD packages, while there are lots of other nvidia
> OpenCL ICD packages that presumably work too.
It won't surprise me if .*-nvidia fails to work with a non-nvidia OpenCL
implementation.
> I have attached a package list and dd-list for these issues.
>
> Perhaps there should be a default-opencl-icd virtual package?
Usable OpenCL implementation is very device specific. We cannot make
sure what OpenCL implementation will always be avaialble on user devices,
and even our buildd.
If there must be a default, pocl-opencl-icd is the solution. It supports runing
OpenCL kernels on CPU, so it should be working on most hosts.
Just don't expect any higher performance from CPU-based OpenCL.
FYI: to verify what OpenCL is usable on your host, you may just
$ sudo apt install clinfo; clinfo
> Perhaps lintian should flag situations where the dep isn't just
> default-opencl-icd | opencl-icd? or is missing opencl-icd?
>
> Thoughts?
I think the current status for some typical packages, like python3-pyopencl
is already correct.
$ apt show python3-pyopencl
Depends: ..., pocl-opencl-icd | mesa-opencl-icd | opencl-icd, ...
You see pocl there as the first choice. For any other packages
that depend on opencl, I think maintainers might have an idea
on what opencl implementation is preferred, either inclusively
or exclusively.
> PS: I noticed this because beignet-opencl-icd is RC-buggy. This is the
> only OpenCL ICD implementation package I can see that supports Intel
> Ivy Bridge, but it is hard to tell which other packages support this,
> because some descriptions don't mention which hardware is supported.
It looks the intel-opencl-icd does not support very old CPUs,
(as listed here https://github.com/intel/compute-runtime )
but I think most major users of OpenCL depends on dedicated GPUs.
The performance of integrated graphics seems no different than nothing.
I think all OpenCL ICD providers can be found by $ apt search opencl-icd .
The AMD opencl implementation is missing.
It is a part of ROCm (https://github.com/RadeonOpenCompute/ROCm-OpenCL-Runtime
),
and indeed something to work on for the ROCm team in the
future.
Bug#1038423: ITP: maven-native -- plugin to compile c and c++ source via maven
Package: wnpp Severity: wishlist Owner: Joseph Nahmias X-Debbugs-Cc: debian-devel@lists.debian.org, mojohaus-...@googlegroups.com, pkg-java-maintain...@lists.alioth.debian.org, j...@nahmias.net * Package name: maven-native Version : 1.0-alpha-11 Upstream Contact: mojohaus-...@googlegroups.com, * URL : https://www.mojohaus.org/maven-native/native-maven-plugin/ * License : Expat Programming Lang: Java Description : plugin to compile c and c++ source via maven This maven plugin creates a custom build lifecycle suited to compiling native C and C++ code using standard compilers such as gcc. . Use cases / usage examples include: . * Building a DLL with JNI. * Building a standard Unix shared library. * Building a static library, including ranlib.
Re: re-introduction of epoch? #1037190 dhcpcd: version is lower than in wheezy
On Sat, Jun 17, 2023 at 11:44 PM Andreas Beckmann wrote:
>
> On 17/06/2023 20.30, Martin-Éric Racine wrote:
> > This is what I would do if the archive policy demands it. Won't affect
> > transitional dhcpcd5 or dhcpcd-base.
>
> Ack.
>
> I'm not sure whether the transitional dhcpcd5 package should have a
> versioned dependency on the "right" dhcpcd, either
> (= 1:${binary:Version}) or (>= 1:9). IIRC you need to add the epoch
> manually in the former case.
Merely re-introducing the epoch for bin:dhcpcd ought to be enough.
dhcpcd5 depends on a versionless dhcpcd. Thus:
override_dh_gencontrol:
dh_gencontrol --package=dhcpcd -- -v1:$(DEB_VERSION_UPSTREAM_REVISION)
dh_gencontrol --remaining-packages
Would probably be enough to make this policy-compliant again.
Martin-Éric
opencl-icd virtual package(s)?
[BCCed to OpenCL ICD implementation package maintainers]
I noticed that some packages have a dep on specific OpenCL ICD
packages, but don't dep on the opencl-icd virtual package(s).
Presumably any of the OpenCL ICDs work for most packages?
$ grep-aptavail --no-field-names --show-field Package --field
Depends,Recommends,Suggests --whole-pkg '(' --pattern .*opencl-icd.* --
and --not --pattern '^opencl-icd(-1\.[1]2-1)?$' ')'
In addition, I noticed that hashcat-nvidia (which presumably doesn't
need to depend on the opencl-icd virtual package) only depends on two
of the nvidia OpenCL ICD packages, while there are lots of other nvidia
OpenCL ICD packages that presumably work too.
I have attached a package list and dd-list for these issues.
Perhaps there should be a default-opencl-icd virtual package?
Perhaps lintian should flag situations where the dep isn't just
default-opencl-icd | opencl-icd? or is missing opencl-icd?
Thoughts?
PS: I noticed this because beignet-opencl-icd is RC-buggy. This is the
only OpenCL ICD implementation package I can see that supports Intel
Ivy Bridge, but it is hard to tell which other packages support this,
because some descriptions don't mention which hardware is supported.
--
bye,
pabs
https://wiki.debian.org/PaulWise
hashcat
leela-zero
libhmsbeagle1v5
libreoffice-calc
libpocl2
python3-pyopencl
boinc-client-opencl
hashcat-nvidia
nvidia-opencl-dev
nvidia-libopencl1
nvidia-opencl-common
beignet-dev
intel-opencl-icd-dbgsym
mesa-opencl-icd-dbgsym
beignet-opencl-icd-dbgsym
Andreas Beckmann
pyopencl (U)
Andreas Tille
libhmsbeagle (U)
Chris Halls
libreoffice (U)
Daniel Echeverry
hashcat (U)
Debian BOINC Maintainers
boinc
Debian LibreOffice Maintainers
libreoffice
Debian Med Packaging Team
libhmsbeagle
Debian OpenCL Maintainers
pyopencl
Debian Security Tools
hashcat
hashcat-meta
Gianfranco Costamagna
boinc (U)
Guo Yixuan (郭溢譞)
boinc (U)
Raphaël Hertzog
hashcat-meta (U)
Rene Engelhard
libreoffice (U)
Steffen Moeller
boinc (U)
Tomasz Rybak
pyopencl (U)
Ximin Luo
leela-zero
signature.asc
Description: This is a digitally signed message part
Debian Med video conference tomorrow Sunday 2023-06-18 18:00 UTC
Hi, this is the call for the next video conference of the Debian Med team that are an established means to organise the tasks inside our team. Meetings usually take us only 15-20min depending what we are talking about and how many people are joining. The next meeting is tomorrow https://www.timeanddate.com/worldclock/fixedtime.html?iso=20230618T18 The meeting is on the Debian Social channel https://jitsi.debian.social/DebianMedCovid19 These video meetings were started in the Debian Med Biohackathon. The topic is what contributors have done in the past period and to coordinate the work until the next meeting. For those who are interested in hot topics we want to tackle, here are some items: - New tasks after bookworm release Newcomers are always welcome. Lets keep on the great work and see you on Sunday Andreas. -- http://fam-tille.de
Re: re-introduction of epoch? #1037190 dhcpcd: version is lower than in wheezy
On 17/06/2023 20.30, Martin-Éric Racine wrote:
This is what I would do if the archive policy demands it. Won't affect
transitional dhcpcd5 or dhcpcd-base.
Ack.
I'm not sure whether the transitional dhcpcd5 package should have a
versioned dependency on the "right" dhcpcd, either
(= 1:${binary:Version}) or (>= 1:9). IIRC you need to add the epoch
manually in the former case.
Andreas
Re: re-introduction of epoch? #1037190 dhcpcd: version is lower than in wheezy
On Sat, Jun 17, 2023 at 6:39 PM Guillem Jover wrote: > By reading #594672 and a quick skim over #551034, these seem to have > been the same project, but the version introduced later as dhcpcd5 was > a new major version with an incompatible redesign, which would break > on upgrade, that's why it was not packaged at the time using the same > source package. So to me it makes sense to avoid adding the epoch to > avoid automatic upgrades like it was avoided in the past, otherwise > people might expect a smooth upgrade path. Also for reference the old > dhcpcd was removed from Debian in 2014: > > https://packages.qa.debian.org/d/dhcpcd.html 2016. > Unfortunately, even though this was long ago, there seems to still be > a short tail of such package installed on systems: > > https://qa.debian.org/popcon.php?package=dhcpcd5 Most of these are likely the result of transitional dhcpcd5 pulling in dhcpcd. > > The bug seems to only affect your binary package dhcpcd, so > > maybe a possible option could be to move ressources provided by > > the dhcpcd package to dhcpcd5 and remove the dhcpcd package. It > > would avoid you the epoch bump and the hassle to handle the > > version bump from the old fork, but it also might confuse people > > using the package. What do you think? > > The only problem I see with leaving things as is, is that some users > might not notice they need to upgrade. It would be nice if we had some > way to notify of these kind of obsolete packages or upgrades. > > But if you end up deciding on adding the epoch, then yeah please, just > add it to the affected binary package (even though in this case that > matches the source package, so it's going to be sticking forever I guess > anyway :/). # Wheezy had (1:3.2.3-11+deb7u1) so reintroduce the epoch for one target. override_dh_gencontrol: dh_gencontrol --package=dhcpcd -- -v1:$(DEB_VERSION_UPSTREAM_REVISION) dh_gencontrol --remaining-packages This is what I would do if the archive policy demands it. Won't affect transitional dhcpcd5 or dhcpcd-base. Martin-Éric
Re: New deprecation warning in CMake 3.27
Hi David, * David Kalnischkies [2023-06-17 13:23]: fwiw apt would trigger this in its autopkgtest as one of them (the main run-tests) builds a sub-directory of helpers with cmake via the main "upstream" CMakeList.txt file. That test is allowed to have stderr output through, so no problem on that front. I just report this back as I think its a bit optimistic to assume everything building something in tests would do so from within debian/tests. I would actually hope most would build some part of upstream like apt instead… just saying. That is true, but I could not think of a simple way to detect that from source code only. Looking for all cmake_minimum_required() created *a lot* of false positives, where the warning will only show up in the buildd log and do no harm otherwise. (I doubt there is any reason apt uses that particular version, but my cmake knowledge is on a pure edit-semi-randomly-until-it-seems-to- work-as-wanted basis) You are not the only one, not by a long shot. :) Being backwards compatible is CMake's greatest blessing and greatest curse at the same time, because people still run into crappy, 20 year old tutorials and needlessly complicated (but working) code snippets from CMake 2.x on the Internet, making them believe that CMake is crappy and needlessly complicated. It is better than its reputation. It does lack good, recent tutorials though. Can you recommend a relatively safe & old version to use instead of < 3.5 which doesn't need bumping next month but is also available in most semi-current releases of all major distributions (as that is what most upstreams will care about if they don't have special needs)? The *correct* minimum version is actually not that easy to determine, because CMake, for some reason, will let you say "cmake_minimum_required(VERSION 3.0)" and still use newer commands such as "add_link_options" (introduced in CMake 3.13) without warning. Speaking of 3.13, Buster aka oldoldstable ships with CMake 3.13 (released in 2018) and Repology tells me that any relevant distribution with an older CMake is either completely unsupported or you need to buy LTS for it. That sounds like a reasonable support baseline to me. More elegant is a version range: if your script does not give any policy warnings with a recent CMake (say CMake 3.26), you can write something like "cmake_minimum_required(VERSION 3.0...3.26)", which will continue to work with old CMake releases but not trigger any support warnings for the forseeable future, because only the upper bound is considered for that. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: 64-bit time_t transition for 32-bit archs: a proposal
On Tue, 2023-06-13 at 21:41:50 -0700, Steve Langasek wrote: > After thinking about it, I'd like to suggest the following approach. > > - dpkg with the new default behavior uploaded to experimental > - libraries uploaded to experimental with the new package names (so, NEW > processing gets done) and with a versioned build-dependency (easy to > automate with sed on debian/control) > - once all the libraries have cleared NEW, copy to unstable without dropping > the versioned build-dependency; it will never be wrong, it will always at > most be cruft that can be cleaned up lazily > > What do you think? Yeah, sounds good to me. > On Thu, Jun 08, 2023 at 04:06:08AM +0200, Guillem Jover wrote: > > On Mon, 2023-05-22 at 18:17:44 -0700, Steve Langasek wrote: > > > > Hmm, rechecking the script, I think we'd want to at least > > > > unconditionally add the Breaks and Replaces (no need for substvars > > > > then), otherwise we'd get upgrade errors? > > > > > That would leave only the Provides as potentially conditional… > > > > You're absolutely right, thanks for catching this! Fixed in git. > > > As hinted above, I think the source:Version substvar should be > > switched to a hardcoded version at the point the migration was done, > > otherwise it will be floating forward and not catch older affected > > versions? > > Oh ok, I didn't catch that this is what you meant. But it's not clear to me > what you mean by "not catch older affected versions" - why would it be wrong > to Breaks/Replaces against non-existent, newer versions of an obsolete > binary package name? Err, sorry right, that paragraph didn't make much sense, I think I might have lost context between the first time I checked this and the next. :) > It's not a difficult change to make, I just don't understand why it's > important. Rereading my own comment, I think what I might have been thinking about was that the version restrictions do not make much sense, and would not protect against potential reintroduction of those obsolete package (probably not in Debian but elsewhere). So probably not important in the Debian context, but it would seem more correct and future-proof to me to completely drop the version restrictions? > > Just to try to understand whether we are on the same page. If these > > libraries have no time_t usage at all, then disabling time64 should > > then provoke no time_t issue and should stop implicitly enabling LFS. > > But if the library contains internal time_t usage that is not part of > > the exposed ABI, but part of its operation, then I'm not sure I see > > how we can patch them to disable LFS w/o at the same time losing > > time64 support (as the latter forces/requires the former). > > > I'm not sure whether you are talking about the first or second case? > > And whether we have no libraries at all falling under the second case? > > I was only thinking about the first case, I had not previously considered > the second case. We should be able to determine fairly easily whether there > are any in the second case; for all ELF binaries which are built from the > same source package as an LFS-sensitive library, check whether they have > references to any of the static list of symbols in glibc that are affected > by time_t, and if they are, add them to the list of libraries to transition. > > I'll add this to the analysis in progress. Perfect, thanks! Regards, Guillem
Re: re-introduction of epoch? #1037190 dhcpcd: version is lower than in wheezy
Hi! On Sat, 2023-06-17 at 11:39:51 +0200, Étienne Mollier wrote: > Martin-Éric Racine, on 2023-06-16: > > Someone filed a bug asking to re-introduce an epoch. > > > > An older fork of the same package back in Wheezy last featured the epoch. > > > > Personally, I'm fine with either marking the bug as WONTFIX or > > re-introducing the epoch for one specific binary target whose name > > matches what was last seen in Wheezy. I simply want to hear what is > > the mailing list's concensus. > > Hmn, hard to tell, I tend to believe the severity is justified, > as one could have carried the old dhcpcd package over a number > of Debian versions since wheezy, and won't get the dhcpcd you > introduced. While I guess in general and in theory this would apply, in this particular case I think the following does make some sense: > On the other hand, you mention your package is a > different implementation, so perhaps the version bump from the > old fork to your package might have unintended effects, for > instance if configuration file formats and such were to have > evolved. By reading #594672 and a quick skim over #551034, these seem to have been the same project, but the version introduced later as dhcpcd5 was a new major version with an incompatible redesign, which would break on upgrade, that's why it was not packaged at the time using the same source package. So to me it makes sense to avoid adding the epoch to avoid automatic upgrades like it was avoided in the past, otherwise people might expect a smooth upgrade path. Also for reference the old dhcpcd was removed from Debian in 2014: https://packages.qa.debian.org/d/dhcpcd.html Unfortunately, even though this was long ago, there seems to still be a short tail of such package installed on systems: https://qa.debian.org/popcon.php?package=dhcpcd5 > The bug seems to only affect your binary package dhcpcd, so > maybe a possible option could be to move ressources provided by > the dhcpcd package to dhcpcd5 and remove the dhcpcd package. It > would avoid you the epoch bump and the hassle to handle the > version bump from the old fork, but it also might confuse people > using the package. What do you think? The only problem I see with leaving things as is, is that some users might not notice they need to upgrade. It would be nice if we had some way to notify of these kind of obsolete packages or upgrades. But if you end up deciding on adding the epoch, then yeah please, just add it to the affected binary package (even though in this case that matches the source package, so it's going to be sticking forever I guess anyway :/). Thanks, Guillem
Re: re-introduction of epoch? #1037190 dhcpcd: version is lower than in wheezy
On Sat, Jun 17, 2023 at 12:40 PM Étienne Mollier wrote: > Martin-Éric Racine, on 2023-06-16: > > Someone filed a bug asking to re-introduce an epoch. > > > > An older fork of the same package back in Wheezy last featured the epoch. > > > > Personally, I'm fine with either marking the bug as WONTFIX or > > re-introducing the epoch for one specific binary target whose name > > matches what was last seen in Wheezy. I simply want to hear what is > > the mailing list's concensus. > > The bug seems to only affect your binary package dhcpcd, so > maybe a possible option could be to move ressources provided by > the dhcpcd package to dhcpcd5 and remove the dhcpcd package. It > would avoid you the epoch bump and the hassle to handle the > version bump from the old fork, but it also might confuse people > using the package. What do you think? If you look at the other open bug, the point precisely was to get rid of the 5 completely. I found a simple override that would re-introduce the epoch only for bin:dhcpcd (but not for bin:dhcpcd-base or the transitional bin:dhcpcd5). I however wonder whether this is worth the trouble, given how far back the last occurrence of bin:dhcpcd goes. This being said, archive policy might mandate doing this even if the last occurrence of bin:dhcpcd dates back from 2016. Martin-Éric
Re: New deprecation warning in CMake 3.27
On Fri, Jun 16, 2023 at 01:08:08AM +0200, Timo Röhling wrote: > Attached is a list of most likely affected packages, which > I generated with a code search for > > (?i)cmake_minimum_required\s*\(\s*version\s*(?:3\.[01234]|2)(?:[.)]|\s) fwiw apt would trigger this in its autopkgtest as one of them (the main run-tests) builds a sub-directory of helpers with cmake via the main "upstream" CMakeList.txt file. That test is allowed to have stderr output through, so no problem on that front. I just report this back as I think its a bit optimistic to assume everything building something in tests would do so from within debian/tests. I would actually hope most would build some part of upstream like apt instead… just saying. (I doubt there is any reason apt uses that particular version, but my cmake knowledge is on a pure edit-semi-randomly-until-it-seems-to- work-as-wanted basis) Can you recommend a relatively safe & old version to use instead of < 3.5 which doesn't need bumping next month but is also available in most semi-current releases of all major distributions (as that is what most upstreams will care about if they don't have special needs)? Best regards David Kalnischkies signature.asc Description: PGP signature
Re: re-introduction of epoch? #1037190 dhcpcd: version is lower than in wheezy
Hi Martin-Éric, Martin-Éric Racine, on 2023-06-16: > (non-subscriber, please keep me in CC) Acknowledged. > Someone filed a bug asking to re-introduce an epoch. > > An older fork of the same package back in Wheezy last featured the epoch. > > Personally, I'm fine with either marking the bug as WONTFIX or > re-introducing the epoch for one specific binary target whose name > matches what was last seen in Wheezy. I simply want to hear what is > the mailing list's concensus. Hmn, hard to tell, I tend to believe the severity is justified, as one could have carried the old dhcpcd package over a number of Debian versions since wheezy, and won't get the dhcpcd you introduced. On the other hand, you mention your package is a different implementation, so perhaps the version bump from the old fork to your package might have unintended effects, for instance if configuration file formats and such were to have evolved. The bug seems to only affect your binary package dhcpcd, so maybe a possible option could be to move ressources provided by the dhcpcd package to dhcpcd5 and remove the dhcpcd package. It would avoid you the epoch bump and the hassle to handle the version bump from the old fork, but it also might confuse people using the package. What do you think? Have a nice day, :) -- Étienne Mollier Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da Sent from /dev/pts/2, please excuse my verbosity. signature.asc Description: PGP signature
