Bug#1056335: ITP: libbgcode -- Prusa Block & Binary G-code reader / writer / converter
Package: wnpp Severity: wishlist Owner: Chow Loong Jin X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: libbgcode Version : 0.0~git20231116.bc390aa Upstream Contact: Vojtech Bubnik * URL : https://github.com/prusa3d/libbgcode * License : AGPL-3.0 Programming Lang: C++, Python Description : Prusa Block & Binary G-code reader / writer / converter libbgcode is a library used to generate binary G-code for 3D printers. Binary G-code is a new G-code file format featuring the following improvements over the legacy G-code: . 1) Block structure with distinct blocks for metadata vs. G-code 2) Faster navigation 3) Coding & compression for smaller file size 4) Checksum for data validity 5) Extensivity through new (custom) blocks. For example, a file signature block may be welcome by corporate customers. I will be packaging this library under the Debian 3-D Printing Packages team as a build-dependency of slic3r-prusa. -- Kind regards, Loong Jin signature.asc Description: PGP signature
Bug#1056357: general: Command line of any program invocation is limited to less than 3544 bytes
Package: general Severity: important X-Debbugs-Cc: br...@clisp.org I'm using Debian GNU/Linux on hppa, in a virtual machine emulated by QEMU 8.0.2. $ uname -srm Linux 6.3.0-2-parisc parisc In this machine, for the invocation of any program, the length of the command line (= all arguments together) is limited to less than 3544 bytes. How to reproduce: In bash: $ /bin/echo `seq 913` -bash: /bin/echo: Argument list too long In dash: $ /bin/echo `seq 913` dash: 1: /bin/echo: Argument list too long I also see this while doing "make check" of packages that have more than 1000 tests. So, it appears to be a general problem. The values returned by getconf don't match the reality: $ getconf ARG_MAX 2097152 $ getconf _POSIX_ARG_MAX 2097152 I have looked at the values of several files in /sys/kernel and /proc/sys/kernel, without finding the cause. For comparison, in a different VM, running "Linux 6.3.7-t2 parisc" (from the T2-SDE distribution), I don't observe this bug. Both machines have the same amount of "physical" RAM: 256 MiB. The ulimit values don't appear to be the cause, because they are similar in the two machines: In the Debian VM (with the bug): $ ulimit -a real-time non-blocking time (microseconds, -R) unlimited core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 849 max locked memory (kbytes, -l) 65536 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size(512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 849 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited In the T2-SDE machine, with no bug: $ ulimit -a real-time non-blocking time (microseconds, -R) unlimited core file size (blocks, -c) 1048575 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 909 max locked memory (kbytes, -l) 8192 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size(512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 909 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited
Bug#1056357: general: on hppa, command line of any program invocation is limited to less than 3544 bytes
Control: retitle -1 general: on hppa, command line of any program invocation is limited to less than 3544 bytes Control: severity -1 wishlist On Tue, 21 Nov 2023 at 17:26:46 +0100, Bruno Haible wrote: > I'm using Debian GNU/Linux on hppa, in a virtual machine emulated by QEMU > 8.0.2. hppa is a "ports" architecture, which is maintained by its port maintainers but not supported by the Debian project as a whole. Debian 6.0 was the last release where hppa was supported as a release architecture, and reached EOL in early 2012. Full text quoted below for the hppa porters (cc'd). /bin/echo `seq 913` seems to work on both 32-bit and 64-bit release architectures (tested 32-bit armhf on the porterbox "abel" and 64-bit amd64 on my laptop) so this appears to be an architecture-specific problem, presumably caused by either different configuration, architecture-specific code paths, or the version of some component being out of date on hppa. > $ uname -srm > Linux 6.3.0-2-parisc parisc > > In this machine, for the invocation of any program, the length of the command > line (= all arguments together) is limited to less than 3544 bytes. > > How to reproduce: > > In bash: > $ /bin/echo `seq 913` > -bash: /bin/echo: Argument list too long > > In dash: > $ /bin/echo `seq 913` > dash: 1: /bin/echo: Argument list too long > > I also see this while doing "make check" of packages that have more than 1000 > tests. So, it appears to be a general problem. > > The values returned by getconf don't match the reality: > $ getconf ARG_MAX > 2097152 > $ getconf _POSIX_ARG_MAX > 2097152 > > I have looked at the values of several files in /sys/kernel and > /proc/sys/kernel, without finding the cause. > > For comparison, in a different VM, running "Linux 6.3.7-t2 parisc" (from the > T2-SDE distribution), I don't observe this bug. Both machines have the same > amount of "physical" RAM: 256 MiB. > > The ulimit values don't appear to be the cause, because they are similar in > the two machines: > In the Debian VM (with the bug): > $ ulimit -a > real-time non-blocking time (microseconds, -R) unlimited > core file size (blocks, -c) 0 > data seg size (kbytes, -d) unlimited > scheduling priority (-e) 0 > file size (blocks, -f) unlimited > pending signals (-i) 849 > max locked memory (kbytes, -l) 65536 > max memory size (kbytes, -m) unlimited > open files (-n) 1024 > pipe size(512 bytes, -p) 8 > POSIX message queues (bytes, -q) 819200 > real-time priority (-r) 0 > stack size (kbytes, -s) 8192 > cpu time (seconds, -t) unlimited > max user processes (-u) 849 > virtual memory (kbytes, -v) unlimited > file locks (-x) unlimited > In the T2-SDE machine, with no bug: > $ ulimit -a > real-time non-blocking time (microseconds, -R) unlimited > core file size (blocks, -c) 1048575 > data seg size (kbytes, -d) unlimited > scheduling priority (-e) 0 > file size (blocks, -f) unlimited > pending signals (-i) 909 > max locked memory (kbytes, -l) 8192 > max memory size (kbytes, -m) unlimited > open files (-n) 1024 > pipe size(512 bytes, -p) 8 > POSIX message queues (bytes, -q) 819200 > real-time priority (-r) 0 > stack size (kbytes, -s) 8192 > cpu time (seconds, -t) unlimited > max user processes (-u) 909 > virtual memory (kbytes, -v) unlimited > file locks (-x) unlimited
Processed: Re: Bug#1056357: general: on hppa, command line of any program invocation is limited to less than 3544 bytes
Processing control commands: > retitle -1 general: on hppa, command line of any program invocation is Bug #1056357 [general] general: Command line of any program invocation is limited to less than 3544 bytes Changed Bug title to 'general: on hppa, command line of any program invocation is' from 'general: Command line of any program invocation is limited to less than 3544 bytes'. -- 1056357: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1056357 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: retitle 1056357 to general: on hppa, command line of any program invocation is limited to less than 3544 bytes
Processing commands for cont...@bugs.debian.org: > retitle 1056357 general: on hppa, command line of any program invocation is > limited to less than 3544 bytes Bug #1056357 [general] general: on hppa, command line of any program invocation is Changed Bug title to 'general: on hppa, command line of any program invocation is limited to less than 3544 bytes' from 'general: on hppa, command line of any program invocation is'. > thanks Stopping processing here. Please contact me if you need assistance. -- 1056357: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1056357 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1056357: general: on hppa, command line of any program invocation is limited to less than 3544 bytes
I'm using Debian GNU/Linux on hppa, in a virtual machine emulated by QEMU 8.0.2. Kernel: Linux 6.3.0-2-parisc parisc PA-RISC Linux kernels starting from 6.2 up until 6.7-rc1 have been lightly tested because I was mostly busy with enabling 64-bit hppa CPU support in qemu. On Debian we currently use kernel 6.1-stable series which works fine with your testcase: "/bin/echo `seq 913`". Starting with Linux kernel 6.7-rc2 the test works OK too, and there is a whole bunch of kernel patches (in 6.7-rc2) currently scheduled to be backported. I suggest you test again in 1-2 weeks (when the patches have been incorporated in the stable series kernels), or try a 6.1-stable or 6.7-rc2 kernel for now. Helge
Bug#1056357: general: Command line of any program invocation is limited to less than 3544 bytes
Yes that's serious because some commands are bigger than 3.5mb, is your machine embedded perhaps? Or have you definitely given the virtual machine enough space and ram to work with? Thanks Zeb On Tue, 21 Nov 2023, 18:30 Bruno Haible, wrote: > Package: general > Severity: important > X-Debbugs-Cc: br...@clisp.org > > I'm using Debian GNU/Linux on hppa, in a virtual machine emulated by QEMU > 8.0.2. > $ uname -srm > Linux 6.3.0-2-parisc parisc > > In this machine, for the invocation of any program, the length of the > command > line (= all arguments together) is limited to less than 3544 bytes. > > How to reproduce: > > In bash: > $ /bin/echo `seq 913` > -bash: /bin/echo: Argument list too long > > In dash: > $ /bin/echo `seq 913` > dash: 1: /bin/echo: Argument list too long > > I also see this while doing "make check" of packages that have more than > 1000 > tests. So, it appears to be a general problem. > > The values returned by getconf don't match the reality: > $ getconf ARG_MAX > 2097152 > $ getconf _POSIX_ARG_MAX > 2097152 > > I have looked at the values of several files in /sys/kernel and > /proc/sys/kernel, without finding the cause. > > For comparison, in a different VM, running "Linux 6.3.7-t2 parisc" (from > the > T2-SDE distribution), I don't observe this bug. Both machines have the same > amount of "physical" RAM: 256 MiB. > > The ulimit values don't appear to be the cause, because they are similar in > the two machines: > In the Debian VM (with the bug): > $ ulimit -a > real-time non-blocking time (microseconds, -R) unlimited > core file size (blocks, -c) 0 > data seg size (kbytes, -d) unlimited > scheduling priority (-e) 0 > file size (blocks, -f) unlimited > pending signals (-i) 849 > max locked memory (kbytes, -l) 65536 > max memory size (kbytes, -m) unlimited > open files (-n) 1024 > pipe size(512 bytes, -p) 8 > POSIX message queues (bytes, -q) 819200 > real-time priority (-r) 0 > stack size (kbytes, -s) 8192 > cpu time (seconds, -t) unlimited > max user processes (-u) 849 > virtual memory (kbytes, -v) unlimited > file locks (-x) unlimited > In the T2-SDE machine, with no bug: > $ ulimit -a > real-time non-blocking time (microseconds, -R) unlimited > core file size (blocks, -c) 1048575 > data seg size (kbytes, -d) unlimited > scheduling priority (-e) 0 > file size (blocks, -f) unlimited > pending signals (-i) 909 > max locked memory (kbytes, -l) 8192 > max memory size (kbytes, -m) unlimited > open files (-n) 1024 > pipe size(512 bytes, -p) 8 > POSIX message queues (bytes, -q) 819200 > real-time priority (-r) 0 > stack size (kbytes, -s) 8192 > cpu time (seconds, -t) unlimited > max user processes (-u) 909 > virtual memory (kbytes, -v) unlimited > file locks (-x) unlimited > >
Bug#1056357: general: on hppa, command line of any program invocation is limited to less than 3544 bytes
Excellent, please explain the bug in question in further detail as this is interesting Thanks Zebb On Tue, 21 Nov 2023, 21:36 Helge Deller, wrote: > > I'm using Debian GNU/Linux on hppa, in a virtual machine emulated by > QEMU 8.0.2. > > Kernel: Linux 6.3.0-2-parisc parisc > > PA-RISC Linux kernels starting from 6.2 up until 6.7-rc1 have been lightly > tested > because I was mostly busy with enabling 64-bit hppa CPU support in qemu. > On Debian we currently use kernel 6.1-stable series which works fine with > your > testcase: "/bin/echo `seq 913`". > Starting with Linux kernel 6.7-rc2 the test works OK too, and there is a > whole > bunch of kernel patches (in 6.7-rc2) currently scheduled to be backported. > > I suggest you test again in 1-2 weeks (when the patches have been > incorporated > in the stable series kernels), or try a 6.1-stable or 6.7-rc2 kernel for > now. > > Helge > >
Bug#1056357: general: Command line of any program invocation is limited to less than 3544 bytes
Zebediah Beck, You haven't read my bug report. Bruno
Misc Developer News (#59)
The news are collected on https://wiki.debian.org/DeveloperNews Please contribute short news about your work/plans/subproject. In this issue: + britney option enabled to look at tests.reproducible-builds.org + reportbug and ftp.d.o/release.d.o/wnpp pseudo-packages + non-free-firmware is now autobuilt + reform.debian.net + new sparc64 porterbox britney option enabled to look at tests.reproducible-builds.org --- Paul Gevers has enabled a no-penalty-no-gain reproducibility option for amd64/arm64/i386/armhf in the migration software, which means that data from the Overview of various statistics about reproducible builds[1] is collected but causes neither migration bonuses nor blocks migration yet. The information only results are visible on https://release.debian.org/britney/update_excuses.html[2] as well as on individual packages pages on the Debian Package Tracker[3]. -- Holger Levsen [1] https://tests.reproducible-builds.org/debian [2] https://release.debian.org/britney/update_excuses.html [3] https://tracker.debian.org reportbug and ftp.d.o/release.d.o/wnpp pseudo-packages -- The reportbug tool now has some features that are useful when filing requests against the pseudo-packages ftp.debian.org, release.debian.org and wnpp. It now sets the usertag for ftp.debian.org removal requests (override requests already had this). This is so that they are automatically categorised correctly on the bug listing. It now sets affects[4] and X-Debbugs-CC[5] on bugs against pseudo-packages that are related to a real package in the archive; including ftp.debian.org, release.debian.org and wnpp bugs (wnpp bugs only had affects before). This is so that maintainers, package tracker subscribers and folks viewing the bug lists for packages can see them. Please consider using reportbug for filing removal or wnpp bugs so that these things are done automatically for you. Some examples of the headers it sets are listed below. If you have bug templates of your own for these issues, please update them to include the correct pseudo-headers. Please note that reportbug supports sending bugs via your normal mail client[6] using xdg-email (available since bullseye), or via a specific mail client[7] too. Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: f...@packages.debian.org Control: affects -1 + src:foo Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: override X-Debbugs-Cc: f...@packages.debian.org Control: affects -1 + src:foo Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm X-Debbugs-Cc: f...@packages.debian.org Control: affects -1 + src:foo Package: wnpp Severity: normal X-Debbugs-Cc: f...@packages.debian.org Control: affects -1 + src:foo -- Paul Wise [4] https://www.debian.org/Bugs/server-control#affects [5] https://www.debian.org/Bugs/Reporting#xcc [6] https://wiki.debian.org/reportbug#Using_your_normal_mail_client [7] https://wiki.debian.org/reportbug#Using_a_specific_mail_client non-free-firmware is now autobuilt -- non-free-firmware in unstable and experimental is now being autobuilt by the regular Debian builders. It is subject to the same allowlist and criteria[8] as regular non-free builds. Allowlisting packages has been staffed with only a single person in the last years. If you are a DD and interested in helping out with license reviews, please contact the same email address. -- Philipp Kern [8] https://www.debian.org/doc/manuals/developers-reference/pkgs.html#non-free-buildd reform.debian.net - Owners of a MNT Reform open hardware laptop[9] can now set up their machine using OpenPGP signed packages built for Debian stable (Bookworm) instead of using unsigned packages for unstable from the official MNT repositories. In addition to the apt repository[10] containing the Bookworm kernel with required patches on top, reform.debian.net provides system images[11] which boot directly into a full Desktop as well as Debian installer netboot images[12] patched with the custom kernel required for the Reform. This service is for the MNT Reform what raspi.debian.net is for the Raspberry Pi. Many thanks go to the debian.net team for providing an ARM64 machine that builds the packages and images and hosts the website. Head over to reform.debian.net[13] for more information. [9] https://shop.mntre.com/products/mnt-reform [10] https://reform.debian.net/repo/ [11] https://reform.debian.net/images/ [12] https://reform.debian.net/d-i/ [13] https://reform.debian
Re: Bug#1042428: lintian.debian.org off ?
On 19/11/23 at 23:49 -0700, Otto Kekäläinen wrote: > > > This issue still exists. I would now have the need to send the url > > > https://lintian.debian.org/tags/service-file-is-not-a-file to upstream > > > developers to learn about this Lintian issue, but the URL does not > > > serve any contents nor does it redirect to a new location. > > > > > > I am still willing to contribute the Apache/Nginx rewrite rules if > > > somebody can point me to a code repository where I can read/contribute > > > at like I announced on September 27th in this thread. > > > > I finally fixed this. Sorry for the delay. > > > > https://udd.debian.org/lintian?packages=entr has a link for each lintian > > tag, that points to (e.g.) > > https://udd.debian.org/lintian-tag.cgi?tag=superfluous-file-pattern > > That page includes a description of the tag as well as all packages > > affected by the tag. > > Thanks! > > Could you consider setting up also redirects from old url, as it seems > that search engines had it indexed pretty well and tend to offer links > to lintian.debian.org as the primary result on on searches for various > Lintian errors? > > https://lintian.debian.org/tags/([a-z-]*)/?$ > -> > https://udd.debian.org/lintian-tag.cgi?tag=$1 That would be something for DSA to do. @DSA: alternatively, maybe you could setup lintian.debian.org as served by an apache on ullmann.debian.org, and managed by the uddadm group? Then I could handle redirects myself. Lucas
Bug#1056357: general: Command line of any program invocation is limited to less than 3544 bytes
Yes, I did see it. But I couldn't reproduce it at the moment as I don't have access to my Linux tools On Wed, 22 Nov 2023, 01:39 Bruno Haible, wrote: > Zebediah Beck, > > You haven't read my bug report. > > Bruno > > > >
