Re: Wolfram Research Debian Package Submission
Control: tags 1032150 wontfix Hello Blake, (Dropping several mails from CC, as those are the wrong adressees for the topic; Adding the ITP bug though, as the discussion should happen there.) On Fri, Jan 12, 2024 at 09:42:18AM -0600, Blake Gilbert wrote: > Hello, > > My name is Blake Gilbert and I work in the partnerships group at > Wolfram Research. > > I am reaching out to you regarding a recent package submission by our > Engine Connectivity Engineering team. We submitted the package CDImage > M-LINUX-WolframEngine.DEB a few months ago to include Wolfram Engine > in Debian packages, and I wanted to see if there was some way to help > move this project forward. Would you be able to assist with this > process or know the proper person to connect to? As elbrus mentioned already, please consult the resources on https://mentors.debian.net/intro-maintainers/ on packaing, and as you are upstream, this page is important too: https://wiki.debian.org/UpstreamGuide After seeing your mail I was curious and downloaded the deb you've linked in #1032150, and examined it's content. Unfortunatly, your package will need a lots of refactoring until it will be fit for inclusion into Debian. Please consult the linked resources above, and the documents that are linked there, especially the Debian Policy Manual) Here are two examples: - you're shipping everyhing in /opt, - the vendoring of system libraries (eg libssh, but it seems you are shipping everything you need vendored, as your package Depends: on nothing) But there is even a more severe problem, I would even say this makes this bug "wontfix" until this has been resolved. The package's d/copyright has: (...) Prohibited Uses All uses of the Software and other elements of the Free Engine not specifically allowed under these terms or otherwise set forth in alternative or supplemental license agreements or terms of use are prohibited, including, without limitation: (...) distributing, publishing, transferring, sublicensing, lending, leasing, renting or otherwise making available any portion of the Free Engine, including collections of data; copying or allowing copying of the Free Engine or any elements of the Free Engine, except as permitted for the maintenance of a single archival copy of the Engine; Please note the usual IANAL disclaimer, but doesn't this make it legally impossible for Debian to include the package into our archives? Even non-free requires *at least* the permission for (re-)distribution and all those associated rights you need that you actually can, technically, do the (re)distribution? I understand that your software is non-free and commercial in nature, and that you do not want to publish the source code. However, not having the source code will make it impossible for Debian to properly maintain the software in Debian [1], especially if Wolfram Alpha loses interest in maintaining it or if there are urgent problems to be fixed. [1] even if non-free is not officially part of Debian, we still want to give our users a good experience -- see our Social Contract. To be honest with you: many people in Debian (including me) will not sponsor packages, when there is no source available, so even if you invest a lot of time into brining the package on a more suitable-for-Debian quality level, there will be no guarantee that your package will be accepted in the end. Other thoughts: - you can always host your own Debian archives, if you wish so, and maintain the package outside of Debian; - Another approach could be to have an package in Debian, which will download and install e.g to the users directory -- for example this is how the package "steam-installer" does it to install Steam.) -- tobi
Re: Ability to further support 32bit architectures
No. You are AGAIN assuming what I am talking about. I know the difference between a 32-bit processor and a 64-bit processor. If you're not going to answer my question, kindly don't answer at all. --J > On Jan 12, 2024, at 21:40, YunQiang Su wrote: > > rhys 于2024年1月13日周六 11:27写道： >> >> Let me try again, following up on the previous thread, but removing most of >> the irrelevant history. >> >> If I have a 32-bit Intel system that is currently supported on bookworm >> (currently running bullseye, but I can upgrade it), is that of use to anyone >> as a native build platform for 32-bit binary packages for Debian? >> > You are yet another person who is confused by the name "i386" vs "amd64". > AMD64 is just the named due to that X86 is extended to X86-64 by AMD *first*. > It means that "Intel 64" or "EM64T" is almost same with "AMD64". > > So, you, the Intel CPU user, should use "AMD64", if you don't clearly > know that your > Intel CPU is 32bit only. > > For more clear, for Debian, "AMD64" is equal to X86-64. > https://en.wikipedia.org/wiki/X86-64 > > -- > YunQiang Su
Re: Ability to further support 32bit architectures
> * Thank you for your offering, but Debian is never in lack of > x86/x86_64/amd64/intel/amd/whatever_you_name_it hardware for package building. > In fact, we now have some of the very powerful machines. If you're sure. Working 32-bit systems are not as common as they once were, and sometimes cross-compliling isn't quite the same (though that's usually a matter of optimization rather than function). I'll leave the offer open in case the need arises. My system is an Intel Atom N270. I keep it around for some simple services but you're welcome to use it if it helps. --J
Re: Ability to further support 32bit architectures
Hi, Am 13.01.24 um 13:59 schrieb rhys: No. You are AGAIN assuming what I am talking about. Maybe because of how you write... I know the difference between a 32-bit processor and a 64-bit processor. Obviously you don't. Or at least are not aware about consequences. Since you still offer 32bit machines of which Debian has enough of. (64 bit kernel probably but it doesn't matter) where it does not matter at all. You ignore the stated fact in this thread that on a 32bit processor one process can't get more than 3GB or even less of RAM (regardless of what memory extension stuff exists). In https://lists.debian.org/debian-kernel/2024/01/msg00191.html (where the quoting is a problem, one doesn't know what is yours and what not) you ignored what YunQiang said in the post you replied to: https://lists.debian.org/debian-kernel/2024/01/msg00189.html Quoting again just for you: "[...] It is about some limitation of 32bit. 2 examples for it: 1. if we use 32bit value for time, it will overflow in 2038, then your time will be shown as 1900. https://en.wikipedia.org/wiki/Year_2038_problem 2. A single process (or maybe APP, not precisely), can only use UP to 4GiB RAM. In fact on most system the value is less than 4GiB: on intel32, it is 3GiB on mips32, it is 2GiB But currently, it is not enough, for example, when we build a big APP, it will need much more RAM. The RAM does install in your Rack, but you can NOT use it. https://en.wikipedia.org/wiki/3_GB_barrier " And THAT (2.) is the problem here for linking big applications/compile units. Not the lack of machines. And that is a limitation of *the architecture*. Putting more "32bit machines" on it do not change anything of that except that there were more machines which cannot build big stuff. Regards, Rene
Bug#1060757: ITP: libdata-find-perl -- Find data in arbitrary data structures
Package: wnpp Severity: wishlist Owner: "Francesco P. Lovergine" X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: libdata-find-perl Version : 0.03 Upstream Contact: Andy Armstrong * URL : https://github.com/AndyA/Data--Find * License : Perl Programming Lang: Perl Description : Find data in arbitrary data structures A simple module to navigate a Perl data structure with three exported subroutines (diter, dfind and dwith) and find data occurrences. -- ⢀⣴⠾⠻⢶⣦⠀ Francesco Paolo Lovergine ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ 0579 A97A 2238 EBF9 BE61 ⠈⠳⣄ ED02 0F02 A5E1 1636 86A4
Re: Ability to further support 32bit architectures
On 2024-01-11 18:38, Aurelien Jarno wrote: > On 2024-01-11 13:24, Adrian Bunk wrote: > > On Thu, Jan 11, 2024 at 11:28:19AM +0100, Bastian Blank wrote: > > >... > > > On Thu, Jan 11, 2024 at 09:48:34AM +, Dimitri John Ledkov wrote: > > > > Disabling debug symbols, enabling debug symbol zstd compression, using > > > > split debug symbols (disabled BTF usage) should help here. > > > > > > Okay, maybe more workarounds exist. But none of them look really > > > promising. > > >... > > > > gcc being a memory hog on for C++ code is a hard problem, > > and debug symbols for C++ code can be a problem since > > they might be > 1 GB for some binaries. > > > > But gcc needing more than 4 GB for a small C kernel driver is not > > a problem for the "Ability to further support 32bit architectures", > > that's a gcc bug that should be reported upstream just like you wouldn't > > suggest dropping amd64 if gcc would ICE on one kernel driver on that > > architecture. > > Or maybe just blame the kernel instead: > https://lore.kernel.org/lkml/CAHk-=whkGHOmpM_1kNgzX1UDAs10+UuALcpeEWN29EE0m-my=w...@mail.gmail.com/ And following the suggestion in that thread, I have just sent a patch fixing the issue: https://lore.kernel.org/lkml/20240113183334.1690740-1-aurel...@aurel32.net/T/#u -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Re: Offer to make a native 32-bit system avaiable
>> I know the difference between a 32-bit processor and a 64-bit processor. > > Obviously you don't. Or at least are not aware about consequences. > > > Since you still offer 32bit machines of which Debian has enough of. (64 bit > kernel probably but it doesn't matter) where it does not matter at all. Then let me be clearer. I should have changed the subject line, because I was not attempting to address the build problems brought up in the original topic. I have done so now. Let me say that again another way: I was changing the subject of the conversation away from the build issues mentioned previously. I did not mean that offering additional resources would solve known build problems. What I mean was, "Here is a resource that appears to be scarce from my perspective. You may use it if you wish." > You ignore the stated fact in this thread that on a 32bit processor one > process can't get more than 3GB or even less of RAM (regardless of what > memory extension stuff exists). Correct. Because that's not relevant to the point I was trying to make. Please see above. > Putting more "32bit machines" on it do not change anything of that except > that there were more machines which cannot build big stuff. Correct. I have and use 32-bit systems. I would like to keep using Debian on those systems. My intention was to offer a resource that could, potentially, help ensure that 32-bit systems continue to be supported. In this way, I am offering to contribute something back to the project that has served me well for years. If that is not useful, that's fine. It's certainly less work for me. It was just an offer. That is all. --J
Re: Offer to make a native 32-bit system avaiable
Thank you for the offer, but no need. It is not needed in Debian infrastructure. On Sat, 13 Jan 2024, 19:18 rhys, wrote: > > > >> I know the difference between a 32-bit processor and a 64-bit processor. > > > > Obviously you don't. Or at least are not aware about consequences. > > > > > > Since you still offer 32bit machines of which Debian has enough of. (64 > bit kernel probably but it doesn't matter) where it does not matter at all. > > Then let me be clearer. > > I should have changed the subject line, because I was not attempting to > address the build problems brought up in the original topic. I have done > so now. > > Let me say that again another way: I was changing the subject of the > conversation away from the build issues mentioned previously. > > I did not mean that offering additional resources would solve known build > problems. > > What I mean was, "Here is a resource that appears to be scarce from my > perspective. You may use it if you wish." > > > You ignore the stated fact in this thread that on a 32bit processor one > process can't get more than 3GB or even less of RAM (regardless of what > memory extension stuff exists). > > Correct. Because that's not relevant to the point I was trying to make. > Please see above. > > > Putting more "32bit machines" on it do not change anything of that > except that there were more machines which cannot build big stuff. > > Correct. > > I have and use 32-bit systems. I would like to keep using Debian on those > systems. My intention was to offer a resource that could, potentially, > help ensure that 32-bit systems continue to be supported. In this way, I > am offering to contribute something back to the project that has served me > well for years. > > If that is not useful, that's fine. It's certainly less work for me. It > was just an offer. > > That is all. > > --J >
32 bit Intel hardware effectively EOL [WAS Re: Offer to make a native 32-bit system avaiable]
On Sat, Jan 13, 2024 at 01:01:08PM -0600, rhys wrote: > > > > > > Since you still offer 32bit machines of which Debian has enough of. (64 bit > > kernel probably but it doesn't matter) where it does not matter at all. > We don't particularly need 32 bit hardware at the moment, as far as I know. > Then let me be clearer. > > I should have changed the subject line, because I was not attempting to > address the build problems brought up in the original topic. I have done so > now. > > Let me say that again another way: I was changing the subject of the > conversation away from the build issues mentioned previously. > > I did not mean that offering additional resources would solve known build > problems. > I think this is the crux of the matter: there are several packages which are problematic - packages needing significant memory resources which are marginal on 32 bit hardware (and often are now built on 64 bit hardware). > What I mean was, "Here is a resource that appears to be scarce from my > perspective. You may use it if you wish." > Thank you for your offer: the resource _is_ scarce, not least because 32 bit hardware is now >> 10 years old and have generally been replaced by 64 bit processors for most purposes. Even if you can make it avaiable to the Debian system administrator's team [DSA] and run it 24/7, it might still end up being unreliable. Your willingness to help is noted and appreciated but it may be too late at this point. > > I have and use 32-bit systems. I would like to keep using Debian on those > systems. My intention was to offer a resource that could, potentially, help > ensure that 32-bit systems continue to be supported. In this way, I am > offering to contribute something back to the project that has served me well > for years. > > If that is not useful, that's fine. It's certainly less work for me. It was > just an offer. > Trixie will still provide some 32 bit programs but not an installer. At this point, it might be that 32 bit hardware can be replaced at minimal cost by a rescued 64 bit laptop or desktop and be both more efficient in terms of power used and usefulness. The EOL clock has been ticking on these sysems for a long time and I think i386 is now really EOL. > That is all. > > --J With every good wish, as ever, Andy (amaca...@debian.org)
Bug#1060771: ITP: python-pyproject-examples -- example pyproject.toml configs for testing
Package: wnpp Severity: wishlist Owner: Josenilson Ferreira da Silva X-Debbugs-Cc: debian-devel@lists.debian.org, nilsonfsi...@hotmail.com * Package name: python-pyproject-examples Version : 2023.6.30 Upstream Contact: Dominic Davis-Foster * URL : https://github.com/repo-helper/pyproject-examples * License : MIT/expat Programming Lang: Python Description : example pyproject.toml configs for testing pyproject-examples was developed with the aim of being used by developers who want to manually test their pyproject.toml configurations. The module serves as a test suite for pyproject.toml analysis tools. . Key Features: - Examples of valid and invalid settings: Provides a series of example files that adhere to the PEP 621 and PEP 517 specifications. Containing example files that demonstrate common configuration errors. - API to access examples: It has functions to retrieve example configurations as strings. - Utilities Module: It has helper functions for creating regular expressions and testing for file not found errors. Nota: module necessary to enable testing of the "whey" package ITP: #1021204
Bug#1060778: ITP: pulsar-edit -- A Community-led Hyper-Hackable Text Editor (formerly Atom)
Package: wnpp Severity: wishlist Owner: Otto Kekäläinen X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: pulsar-edit Version : 1.112.1 Upstream Contact: ad...@pulsar-edit.dev * URL : https://pulsar-edit.dev/ * License : MIT Programming Lang: JavaScript Description : A Community-led Hyper-Hackable Text Editor Anyone can test the app using upstream package https://download.pulsar-edit.dev/?os=linux&type=linux_deb which installs everything in /opt/Pulsar/. This is an Electron app and I am looking for advice from other NodeJS and Electron app maintainers on how to package this properly in Debian.
