Bug#1069270: rendering failure with gtk 4
Package: librnd Severity: serious Version: 4.2.0-1 There appears to be a bug in this version of librnd that prevents successful rendering with the default gtk 4 hid. In the short term, users can work around the problem by installing librnd4-hid-lesstif and invoking the various ringdove tools with option --gui lesstif This is clearly unacceptable for stable release, so until we can figure out and fix the problem in librnd I'm filing this release-critical bug to prevent this version from promoting to testing. Bdale
Bug#1068810: [Pkg-electronics-devel] Bug#1068810:
Gianfranco Costamagna writes: > yes, but the library was renamed in librnd4t64, so either you need to > depend on the new one, or drop it, to let the auto decrufter finish > the time64_t transition and decruft it. Ah, thank you, that's a useful observation. Since the relevant version hasn't made it into testing with the changed library names yet, the easiest course of action is indeed to just drop this dependency, as any version of librnd4t64 that's ever in testing will be "new enough" to meet the new sch-rnd requirement. > Depending on NBS packages is RC critical. FWIW, I had to look up what "NBS" means in this context. A new acronym to me despite being part of Debian since 1994... Bdale signature.asc Description: PGP signature
Bug#1068812: [Pkg-electronics-devel] Bug#1068812: pcb-rnd: hardcoded librnd4 dependency
severity 1068812 minor tags 1068812 +pending thanks Gianfranco Costamagna writes: > Hello, I found that librnd4 is correctly evaluated from shlibs:Depends > in the core library and then it can be dropped also on core > reverse-dependencies. Thanks for the bug report. Fixed in packaging for the next upload. Downgrading since this is clearly not actually a release critical bug. Bdale signature.asc Description: PGP signature
Bug#1068810: [Pkg-electronics-devel] Bug#1068810: sch-rnd: hardcoded librnd4 dependency
Gianfranco Costamagna writes: > Hello, I found that librnd4 is correctly evaluated from shlibs:Depends > in the core library and then it can be dropped also on core > reverse-dependencies. The point of the dependency is to require version 4.1.0 or later, since that's the librnd version that added support for hierarchical design which is required by this and later releases of sch-rnd. > Please drop it. What actual problem are you trying to solve with this bug report? Bdale signature.asc Description: PGP signature
Bug#1068790: please remove yforth
Package: yforth I am the one who originally packaged yforth for Debian in 1997, and am still the sole maintainer of the package. I haven't personally used yforth in a number of years, and the last package update was in 2012. As per bug #1068474, the yforth source code is crufty in ways that make it unlikely to ever work on anything but a 32 bit machine. Upstream has disappeared, and nobody particularly wants to work on modernizing this code. Given the existence of better-maintained Forth interpreters gforth and pforth in Debian, I see no reason to retain yforth. Please remove yforth from the archive. Bdale signature.asc Description: PGP signature
Bug#1068474: yforth segfaults immediately on launching
Sudip Mukherjee writes: > yforth is causing a segfault immediately on startup. Thanks for the bug report. I haven't had reason to use yforth in many years, (the package was last updated on 11 October 2012), so I hadn't noticed! My guess is that this is a simple 64-bit system incompatibility, as a quick rebuild of the package on my current 64-bit laptop yields a large number of warnings about casts of pointer from integer of different size... Honestly, I'm not sure this is worth fixing? The upstream site has disappeared entirely. If someone wants to step through the source and fix all the cast issues, I'd be happy to have a patch. But given the availability of gforth and pforth in Debian, just removing yforth from Debian might be the best plan. Bdale signature.asc Description: PGP signature
Bug#1061001: python3.12 at fault?
This appears to be another manifestation of the incompatibility with python3.12 reported in #1059647. I'm not going to mark it as a duplicate in the BTS since the process of getting there is so different, but I believe the fix will be the same. Upstream has reworked the build process to allow use of python3.12 and a new upstream release is expected as soon as a test suite issue is resolved. Bdale signature.asc Description: PGP signature
Bug#1059647: fixed in upstream branch
tags 1059647 +upstream thanks Upstream reports in https://github.com/scikit-fmm/scikit-fmm/issues/78 that this issue is fixed on a development branch, and will be merged and released as soon as a test suite issue gets resolved. Bdale signature.asc Description: PGP signature
Bug#1066248: test builds successful
tags 1066248 +pending tags 1049315 +pending thanks Last night I successfully completed a test build of librnd from upstream svn trunk that resolves all open Debian bugs. The next upstream release is still expected on 10 April, and I plan to update the Debian librnd package immediately after that release. Bdale signature.asc Description: PGP signature
Bug#1067977: openmotor: Please replace python3-appdirs dependency with platformdirs
tags 1067977 +forwarded thanks Simon McVittie writes: > Package: openmotor > Version: 0.5.0-2 > Severity: important > Control: block 1060427 by -1 > Tags: trixie sid > User: debian-pyt...@lists.debian.org > Usertags: appdirs-removal > > python3-appdirs is dead upstream[1] and its Debian maintainer has indicated > that it should not be included in trixie[2]. A recommended replacement is > python3-platformdirs[3], which is a fork of appdirs with a very similar API. > > Please migrate from appdirs to platformdirs or some other replacement, > so that appdirs can be removed. Filed as an issue with upstream: https://github.com/reilleya/openMotor/issues/225 Bdale signature.asc Description: PGP signature
Bug#1066248: [Pkg-electronics-devel] Bug#1066248: librnd: FTBFS: ../src/librnd/plugins/hid_lesstif/main.c:261:25: error: implicit declaration of function ‘lesstif_attr_sub_update_hidlib’ [-Werror=impl
Peter Michael Green writes: > The functions in question are defined in > src/librnd/plugins/hid_lesstif/dialogs.c > and used in src/librnd/plugins/hid_lesstif/main.c Correct. Upstream has fixed this and will have a new release on 10 April that I'm waiting for rather than patching the current Debian sources. > while working on this issue I discovered that the clean target was not > cleaning up properly, so I fixed that too. Thank you! That's been on my to-do list, will talk to upstream about the lingering files since his build structure should be cleaning up after itself better, I think. Bdale signature.asc Description: PGP signature
Bug#1062412: [Pkg-electronics-devel] Bug#1062412: libmawk: NMU diff for 64-bit time_t transition
Benjamin Drung via Pkg-electronics-devel writes: > Please find attached a final version of this patch for the time_t > transition. This patch is being uploaded to unstable. Thank you! Patch merged into my packaging repo, tagged, and pushed to salsa. Bdale signature.asc Description: PGP signature
Bug#1062610: [Pkg-electronics-devel] Bug#1062610: librnd: NMU diff for 64-bit time_t transition
Benjamin Drung via Pkg-electronics-devel writes: > Please find attached a final version of this patch for the time_t > transition. This patch is being uploaded to unstable. Thank you! Merged into my packaging repo with suitable tag and pushed to salsa. Bdale signature.asc Description: PGP signature
Bug#1064156: O: gcpegg -- GCP (EGG) Software, orphaned because I no longer use it
Package: wnpp This package delivers a persistent daemon to support data collection from hardware random number generators (eggs) to a server (basket) hosted by the Global Consciousness Project, which originated as project of Dr Roger Nelson at Princeton University. The upstream source is https://noosphere.princeton.edu/software.html I hosted one of these data collection devices for many years. I do not believe any new eggs have been added to the network since 2014, and today there is a "GCP 2.0" project and associated network of data collection devices that do not require attachment to a computer, one of which I now host. More information can be found at https://gcp2.net/. I just realized it has been about 5 years since I last touched this package. I don't know if anyone else is (still) using it, but I'm not, and thus am unlikely to ever spend any more time on it. Thus, it's clearly time for me to orphan it. Regards, Bdale signature.asc Description: PGP signature
Bug#1059647: scikit-fmm: autopkgtest failure with Python 3.12
tags 1059647 +help thanks Graham Inggs writes: > Source: scikit-fmm > Version: 2022.08.15-4 > Severity: serious > User: debian-pyt...@lists.debian.org > Usertags: python3.12 > > Hi Maintainer > > scikit-fmm's autopkgtests fail with Python 3.12 [1]. I've copied what > I hope is the relevant part of the log below. It looks like upstream may not be ready for use with Python 3.12, at least in part due to numpy.distutils disappearing. There is an open issue about this at https://github.com/scikit-fmm/scikit-fmm/issues/78 Since upstream doesn't seem to have a fix yet, fixing the Debian package may require someone who understands what's going on offering to help fix the upstream code. Bdale signature.asc Description: PGP signature
Bug#1060349: include file gtksheetfeatures.h not in package
Package: gtksheet Version: 4.3.12+dfsg-3 Attempting to build lepton-eda with this version of the -dev package, I get several examples of the following error: /usr/include/gtksheet-4.0/gtksheet/gtksheet.h:34:10: fatal error: gtksheet/gtksheetfeatures.h: No such file or directory 34 | #include | ^ And, indeed, there appears to be no 'gtksheetfeatures.h' file provided at any path in the -dev package? Bdale signature.asc Description: PGP signature
Bug#967565: [Pkg-electronics-devel] Bug#967565: lepton-eda: depends on deprecated GTK 2
Bastian Germann writes: > With both autotools and meson buildsystems, the gtksheet-4.0/gtksheet > include path is intentional. Then why does pkg-config --cflags "gtksheet-4.0 >= 4.0.0" not include -I/usr/include/gtksheet-4.0 as one of the returned elements? It appears to me that this is what the lepton-eda configure expects to correctly return a path element for the includes. Calling pkg-config with --libs correctly adds -lgtksheet-4.0, so maybe there's something not-quite-right with the info the gtksheet packaging delivers for use by pkg-config --cflags? Bdale signature.asc Description: PGP signature
Bug#967565: [Pkg-electronics-devel] Bug#967565: lepton-eda: depends on deprecated GTK 2
Bastian Germann writes: > Am 20.05.23 um 12:41 schrieb Bastian Germann: >> lepton-eda has gtk3 support. With the lepton-attrib configuration active, >> gtksheet would have to be packaged (#1036393). > > gtksheet is now available in Debian, so please consider switching to > gtk3 soon. It appears that libgtksheet-4.0-dev installs includes with an extra layer of sub-directory. While the application is looking for /usr/include/gtksheet/gtksheet.h, for example, the -dev package installs that file at /usr/include/gtksheet-4.0/gtksheet/gtksheet.h. Is that intentional, or just a mistake? I don't immediately see the value in the extra subdirectory level here. I'm sure I can work around it in the lepton-eda packaging, but if you agree the 'gtksheet-4.0' level is unnecessary, it would be great to see that get fixed instead. Regards, Bdale signature.asc Description: PGP signature
Bug#1059890: [Pkg-electronics-devel] Bug#1059890: lepton-eda: weird short description: "metapackage" ?
tags 1059890 +pending thanks Alexandre Detiste writes: > This does not looks like a metapackage. > Maybe this is an holdover from ancient times. That's entirely possible. Thanks for the report, I've removed the errant word from the short description in git, will be fixed in the next upload. Bdale > > Greetings, > > Alexandre > > ___ > Pkg-electronics-devel mailing list > pkg-electronics-de...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-electronics-devel signature.asc Description: PGP signature
Bug#1055723: rocketcea ftbfs with Python 3.12
You have my permission. Bdale On December 14, 2023 11:54:24 AM MST, Alexandre Detiste wrote: >Hi, > >I ll try to fix this one if you permit. > > >Greetings
Bug#1058273: gpredict: FTBFS: dh_install: error: missing files, aborting
tony mancill writes: > So this is very possibly a bug in libreoffice-writer-nogui. Sure seems like it. My guess would be that what files go in what libreoffice binary packages got refactored somehow? Not sure what the point of the nogui package is if it can't be used here any more. [shrug] I don't have any time to chase this right now. Bdale signature.asc Description: PGP signature
Bug#967684: migrating pcb users to pcb-rnd
If/when gtk2 support is actually removed from Debian, a variation on the theme suggested in #1008060 would seem like a good path forward. We could just replace the 'pcb' meta package with one that depends on pcb-rnd, which is an evolving and well-supported fork that retains complete compatibility for working with designs developed in 'pcb'. Bdale
Bug#1054819: ezdxf: FTBFS: make[2]: *** [Makefile:44: html] Error 2
Lucas Nussbaum writes: > During a rebuild of all packages in sid, your package failed to build > on amd64. I am unable to reproduce this problem building in a fresh, minimal sid chroot environment. Is this a repeatable failure? If so, any thoughts on what might cause it to fail in your build environment but not in my cowbuilder chroot environment? Bdale signature.asc Description: PGP signature
Bug#1036535: unblock: altos/1.9.16-2
Graham Inggs writes: > If this was an upload of 1.9.15-2 with only that change, altos would > already have been unblocked. Right, I understand. However, there would be no value to me or to the users altos to create such a version, it would "only" resolve the Debian file overlap packaging bug which they likely just don't care about. That's why I didn't take that path. > You didn't attach a debdiff, but I generated one in order to review > the changes between 1.9.15-1 in testing and 1.9.16-2 in unstable. The reason I didn't generate it was exactly what you discovered, which is that there's a lot of "noise" in the diff that is unrelated to the code that runs on Linux and/or is actually relevant to the Debian package. > As far as I could see, the only change according to the upstream > release notes was: > * Add TeleGPS v3.0 support > > However, the debdiff showed a lot more, including the addition of > several fonts. The font stuff is all related to working on firmware support for a graphic LCD display we need to support in a future ground station hardware product. Those changes have no impact at all on the code that's executable on a Linux system. Even the addition of support for TeleGPS v3.0 is largely creation of a new firmware object that's not executed on Debian, plus some very minor changes to the Java ground station software to enable support for it, all of which is very low risk. Specifically, because the ground station code is in Java, that change has already been massively tested by our users on other platforms since the 1.9.16 change giving me extremely high confidence there's no risk to including those changes here. > As upstream, please comment on risks of the other changes between > 1.9.15 and 1.9.16. As I stated in the original bug filing, I believe the risk of the other changes is negligible. A large number of customers of Altus Metrum hardware products have been running 1.9.16 for a while now on platforms including Windows, MacOS, Android, and other Linux distributions with .. literally .. no new bugs reported. We will of course support whatever decision you choose to make, but I am quite serious about believing 1.9.16-2 is the best choice of altos version for inclusion in testing and therefore in the upcoming stable release. Thanks for your time on this, and best regards, Bdale signature.asc Description: PGP signature
Bug#1036535: unblock: altos/1.9.16-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: al...@packages.debian.org Control: affects -1 + src:altos Please unblock package altos The altos package is apparently scheduled for autoremoval from testing due to bug #1036022. A fix for that bug is present in version 1.9.16-2. [ Reason ] Prevent removal of altos from testing due to a file overlap with lprint. [ Impact ] Removal of altos from testing (and the upcoming stable release) would disappoint users of the package. [ Tests ] The 1.9.16 upstream release was thorough tested and has been in heavy use by many users across multiple platforms (Linux, Windows, MacOS, Android) for about a month with no new bugs reported. The -2 upload to Debian is a minimal packaging update to fix the file overlap bug. [ Risks ] The altos package is not depended on by any other Debian package, and users of the package would universally prefer 1.9.16-2 to 1.9.15-1. The risk of an unblock therefore seems VERY low. While there were a number of changes between 1.9.15 and 1.9.16, 1.9.16 is well tested and in heavy use. The change for the -2 upload was a one-line change of the delivery path for a rarely-used systemd unit file in the packaging scripts (that is not enabled by default). [ Checklist ] [X] all changes are documented in the d/changelog [X] I reviewed all changes and I approve them [ ] attach debdiff against the package in testing [ Other info ] I am both an upstream and Debian package maintainer of altos. unblock altos/1.9.16-2
Bug#1036178: systemd unit file in wrong place
Package: lprint Severity: important As per bug #1036022, it appears that lprint is delivering a systemd unit file to a place in the file system where it will never be acted on. Because the immediate motivation for that bug, a file overlap conflict with the altos package, was resolved in the latest altos upload, I went ahead and closed that bug. But, the lprint package really should be updated to deliver the systemd unit file correctly. Bdale signature.asc Description: PGP signature
Bug#1035904: dpkg currently warning about merged-usr systems (revisited)
You are of course correct. I remain unconvinced that anything related to the work on merged-/usr to date should be considered as a positive justification for actions discussed in this thread, but we can just let the rest drop. Bdale On May 15, 2023 10:08:00 AM MDT, Matthew Vernon wrote: >On 15/05/2023 16:54, Bdale Garbee wrote: >> I could. >> >> Can you provide an example of actual value delivered to Debian from >> merged-/usr? > >With respect, I don't think this line of argument is going to get us very far >- this bug isn't about whether we should undo usr-merge, so I don't think a >debate on the merits or otherwise of usr-merge is germane. > >[I think this applies to the contrary side of the argument also] > >Regards, > >Matthew >
Bug#1035904: dpkg currently warning about merged-usr systems (revisited)
I could. Can you provide an example of actual value delivered to Debian from merged-/usr? Bdale On May 15, 2023 7:15:53 AM MDT, Luca Boccassi wrote: >On Mon, 15 May 2023 at 13:51, Bdale Garbee wrote: >> >> Merged-/usr seems to me to have brought great pain with no discernable >> benefit to Debian so far, and I at least have completely lost the thread on >> what the point of doing it was supposed to be. So, using it as a >> justification for further harm to user and system expectations isn't >> compelling. > >Are you able to provide an example of such "harm"? > >Kind regards, >Luca Boccassi >
Bug#1035904: dpkg currently warning about merged-usr systems (revisited)
Merged-/usr seems to me to have brought great pain with no discernable benefit to Debian so far, and I at least have completely lost the thread on what the point of doing it was supposed to be. So, using it as a justification for further harm to user and system expectations isn't compelling. Bdale On May 14, 2023 10:48:04 PM MDT, Johannes Schauer Marin Rodrigues wrote: >Hi, > >Quoting Steve McIntyre (2023-05-15 02:54:02) >> On Mon, May 15, 2023 at 12:24:15AM +0100, Luca Boccassi wrote: >> >On Sun, 14 May 2023 at 22:37, Josh Triplett wrote: >> > >> >> The x86-64 ABI is set. Feel free to make the case to the next >> >> architecture designer that their new ABI should have the dynamic linker >> >> in `/usr/lib`. That would *not* have the same downsides, as long as >> >> everyone agrees on a path. >> > >> >In practice it is not, though. There are other distributions that >> >change PT_INTERP for their own purposes, they've already been listed >> >in this thread. And I am still not hearing any concrete, factual use >> >case that would be impaired by such a change. I'm beginning to >> >seriously think there aren't any? Is that really the case? >> >> The ABI has been agreed and set down in documentation that *just >> about* everybody has been following since its inception. This includes >> the most basic set of definitions of what an x86-64 program must look >> like, including the interpreter path. If this path is changed, then >> *at the most basic level* we'd be making programs that are not valid >> by the ABI we've agreed to. This is an *external interface contract*, >> not something we should ever consider changing without significant >> cross- and inter-project discussion. >> >> Pointing at gentoo or nixos as examples of projects that have decided >> to break compatibility doesn't cut it, I'm afraid. They're well known >> for changing fundamental things around Linux and (basically) not caring about >> interoperability. That attitude is *not* Debian's. > >me and Luca have different ideas about how bootstrapping a Debian chroot should >look like and I don't want to make an argument *for* changing PT_INTERP here as >I think that keeping compatibility with others by following ABI is a good thing >and because I think (and hope -- but Helmut is doing that analysis right now) >that the debootstrap problem can be solved in a way I envision without changing >PT_INTERP. But what I do not understand about the argument against Luca's >proposal is: > >Obviously, with Luca's proposal, binaries from packages built with a different >dynamic linker path in them would not work on distributions without merged-/usr >symlinks. But if the property of stuff from Debian being able to run on >non-Debian non-merged-/usr systems is an important one, then why was it okay to >have merged-/usr as the default? Because with merged-/usr we already changed >the interface contract for a lot of things because now binaries and libraries >can also be found at other locations than on non-merged-/usr systems. A script >with a /usr/bin/bash shebang built on and for Debian will not work on a system >without the symlinks. > >So did we not years ago decide, that the result of the "cross- and >inter-project discussion" is, that everybody is going merged-/usr and that's >why we need it too and that's why it is okay to build a system where binaries >and scripts built for it just may not run on those other systems that do not do >it? With merged-/usr we already *did* "change fundamental things around" for >reasons that are really not clear to me (but which i do not want to discuss >here) and as a result did not "care about interoperability" (with those who do >not also adopt it). In my own Debian work I so far only got extra work because >of merged-/usr and I do not see the benefits (yet) and I was hoping that >"changing fundamental things around Linux and (basically) not caring about >interoperability" was *not* Debian's attitude but alas here we are. > >So have we not already burned the bridges to the non-merged-/usr world? Why was >it okay back then to say "we can make this change because all other important >players are doing merged-/usr so we can/have to as well". And now in the >PT_INTERP discussion somehow we care again about those systems? I thought we >already had the "cross- and inter-project discussion" about merged-/usr and >because the result was "yes, go for it" we did it too. But if that is the case, >why do we now care for a subset of the interoperability problems caused by >merged-/usr for systems that don't have it? > >As I said, I don't care much about the PT_INTERP value but I don't understand >yet, why this argument about interoperability with non-merged-/usr systems is >working now but it didn't wasn't enough to stop another very fundamental change >in how we build a Linux distro. > >Thanks! > >cheers, josch
Bug#1031332: transition: librnd
Sebastian Ramacher writes: >> Because I didn't previously know about this process, all application >> packages >> that depend on this new library version (all of which come from the same >> upstream) have already been uploaded and accepted into unstable with build >> dependencies on the binary packages delivered by source package librnd. > > Let's do this transition early in the trixie release circle. That feels like an unfortunate choice, since it leaves the new versions of pcb-rnd, sch-rnd, and camv-rnd already in unstable un-buildable for the duration. But .. I get it .. as you wish. Bdale signature.asc Description: PGP signature
Bug#1031445: [Pkg-electronics-devel] Bug#1031445: camv-rnd: FTBFS: build-dependency not installable: librnd4-dev (>= 3.2.0)
Lucas Nussbaum writes: > Source: camv-rnd > Version: 1.1.1-1 > Severity: serious > Justification: FTBFS > Tags: bookworm sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20230216 ftbfs-bookworm > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. Sadly, librnd v4 is stuck in experimental, denied a transition slot until trixie is opened. All ringdove applications including pcb-rnd, camv-rnd, and sch-rnd will be unbuildable until it migrates to unstable. Bdale signature.asc Description: PGP signature
Bug#1031345: [Pkg-electronics-devel] Bug#1031345: kicad: Please update
Carsten Schoenert writes: > unfortunately this will not happen, it's simply to late get KiCad 7.0.0 > into the next stable release. The same is true for the ringdove suite, including pcb-rnd. > We will work on providing backported packages as usual once the bookworm > release is out. Indeed. Bdale signature.asc Description: PGP signature
Bug#1031332: transition: librnd
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: lib...@packages.debian.org Control: affects -1 + src:librnd This is a fairly trivial transition due to upstream rolling to a new ABI version. I originally uploaded this straight to unstabe, but Thorsten asked me to follow the "via experimental" process. Because I didn't previously know about this process, all application packages that depend on this new library version (all of which come from the same upstream) have already been uploaded and accepted into unstable with build dependencies on the binary packages delivered by source package librnd. Bdale Ben file: title = "librnd"; is_affected = .depends ~ /librnd3/ | .depends ~ /librnd4/; is_good = .depends ~ /librnd4/; is_bad = .depends ~ /librnd3/;
Bug#1011549: openrocket needs newer jogl
tony mancill writes: > But in addition to not yet being done with that, it didn't seem prudent > to try to push this into bookwork at the last minute, and that wouldn't > have given the reverse dependencies any time to react anyway. So I am > going to work towards an upload to experimental soon, and then we can > aim for getting this into unstable/testing after the freeze. I agree. There's no way I'm going to make time to get openrocket into main before bookworm, so I'm fine with this plan. Thank you VERY much for working on this, I really do look forward to having openrocket back in Debian main again! Bdale signature.asc Description: PGP signature
Bug#1011549: openrocket needs newer jogl
Bdale Garbee writes: > I'll talk to openrocket upstream about it and see if I can't get some > clarification about what we actually need and a pointer to the relevant > source code. I just got a pointer to https://github.com/openrocket/openrocket/pull/1958 This appears to document which forks of JOGL and gluegen were used to build openrocket successfully on macOS arm64 architectures. Bdale signature.asc Description: PGP signature
Bug#1027769: closed by Debian FTP Masters (reply to Bdale Garbee ) (Bug#1027769: fixed in cpmtools 2.23-1)
Jacob Nevins writes: > I don't think cpmtools autodetects libdsk, so just adding it to > build-deps isn't sufficient -- I think it's necessary to also invoke > configure with '--with-libdsk' (in this case, '--with-libdsk=/usr', > I think). Thanks, looks fixed in -3. Bdale signature.asc Description: PGP signature
Bug#1029084: closed by Debian FTP Masters (reply to Bdale Garbee ) (Bug#1029084: fixed in cpmtools 2.23-1)
Helmut Grohne writes: > Control: reopen -1 > > On Tue, Jan 24, 2023 at 11:21:09PM +, Debian Bug Tracking System wrote: >> #1029084: cpmtools FTCBFS: multiple reasons >> >> It has been closed by Debian FTP Masters >> (reply to Bdale Garbee ). > > | * cross-building should be fixed by repackaging, closes: #1029084 > > Sorry, no. The stripping issue persists. Hrm. As I DH'ified the package, I really thought that part of your patch would no longer be relevant. What I didn't realize is that your bug about not stripping in dh_auto_install wasn't implemented until compat 11, and the source package was still declaring 10. So .. I've moved the package to debhelper compat level 13, and hope that's sufficient to resolve the problem. However, I do note that /usr/bin/install still seems to be getting called with -s on my amd64 local build? Hoping it does the right thing now on cross builds. Please let me know if there's more I need to do! Regards, Bdale signature.asc Description: PGP signature
Bug#1024510: do not include yet in a Debian stable release
Package: sch-rnd Version: 0.9.3-1 Severity: serious Upstream was happy for me to package sch-rnd for Debian unstable, but would prefer we not include it in a stable release until he makes a stable upstream 1.0 release. Bdale signature.asc Description: PGP signature
Bug#1022385: [Pkg-electronics-devel] Bug#1022385: pcb-rnd: FTBFS: diff: out.copper_p2.svg: No such file or directory
Lucas Nussbaum writes: > Source: pcb-rnd > Version: 3.0.5-3 > Severity: serious > Justification: FTBFS > Tags: bookworm sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20221023 ftbfs-bookworm > > During a rebuild of all packages in sid, your package failed to build > on amd64. Thanks for the report! The problem has been found and fixed by pcb-rnd upstream, and will be included in the pcb-rnd 3.0.6 release, due in about one week from now. I'll plan to package that and upload it as soon as it is released. Bdale signature.asc Description: PGP signature
Bug#1021564: RFP: openrocket -- Rocket simulation software
Petter Reinholdtsen writes: > How is this different from the libjogl2-java package with home page > http://jogamp.org >? The source seem to be available from > https://jogamp.org/wiki/index.php/Jogamp_SCM_Repositories > > pointing to https://github.com/sgothel/ >. See Debian bug #1011549. This led to quite some discussion on the upstream openrocket list openrocket-de...@lists.sourceforge.net, but no path to resolution yet. See, for example: https://sourceforge.net/p/openrocket/mailman/message/37703498/ Frankly, I don't personally care about 3d rendering in openrocket at all, so a reasonable path forward for packaging might be to just disable that functionality entirely. It's "just for show" and doesn't actually affect the process of designing and running flight simulations of a rocket. Bdale signature.asc Description: PGP signature
Bug#1021564: RFP: openrocket -- Rocket simulation software
Petter Reinholdtsen writes: > [Bdale Garbee] >> Are you aware of my existing work on this? > > Not really, but not suprised if you are already looking at it. I just > discovered it lacked a RFP, so decided to make one. :) I'm not sure an RFP is really appropriate, since there's an installer package in contrib already, but ... as you wish. The history of openrocket packaging in Debian is long and ... horrible. Years ago, we had a package in main, that Tom Marble helped me keep working as more Java class library dependencies crept in. Then that got too hard, so I switched to an installer package in contrib. That got horrible over time too both because the upstream jar site kept changing access path(s), and because there was/is a hard dependency on OpenJDK 8. When the upstream development community started putting out beta releases for the first possible stable release since March 2015, I started working on packaging it. There are a few remaining embedded class libraries that need to be unwound, including a JOGL thing for which nobody seems to know where to find complete corresponding upstream source. My work to date can be found at: https://salsa.debian.org/debian/openrocket And packages that aren't quite policy compliant can be found on one of my servers at https://gag.com/apt/ Upstream agrees that the JOGL embedded class library for which they can't point to source is a bad thing, and there's more or less a commitment to work on that eventually... but, in typical Java development style, since the current code "works", upstream's sense of urgency on this is lower than mine. Then .. in the latest twist, Sampo who was the original upstream author re-appeared on the mailing lists in the last few days indicating that he's quietly been working on a complete rewrite of openrocket in Typescript, for which he has quite a bit of code working and wanted to get some community feedback before deciding what to do with this code. It's pretty clear that there's a split between those who would just love to walk away from the Java code base, and those who feel too heavily invested to walk away and, like me, worry about second system syndrome effects here. Anyway. I'd love to have help completing the rest of the work to make my current/new openrocket package policy compliant and thus ready for upload to main... hint, hint! Bdale signature.asc Description: PGP signature
Bug#1021564: RFP: openrocket -- Rocket simulation software
Are you aware of my existing work on this? On October 10, 2022 2:05:49 PM MDT, Petter Reinholdtsen wrote: > >Package: wnpp >Severity: wishlist > >* Package : openrocket > Version : 15.03 > Upstream author : Sibo Van Gool and others >* URL : https://openrocket.info/ >https://github.com/openrocket/openrocket >* License : GPL3+ > Programming Lang: Java > Description : Rocket simulation software > >OpenRocket is a free, fully featured model rocket simulator that allows >you to design and simulate your rockets before you build and flying >them. >-- >Happy hacking >Petter Reinholdtsen
Bug#1018617: rocketcea: build-depends on python3-nose or uses it for autopkgtest
tags 1018617 +help thanks Dmitry Shachnev writes: > Source: rocketcea > Version: 1.1.18+dfsg-2 > User: python-modules-t...@lists.alioth.debian.org > Usertags: nose-rm > > Dear Maintainer, > > Your package still uses nose [1], which is an obsolete testing framework for > Python, dead and unmaintained since 2015 [2][3]. I noticed that upstream is now at 1.1.29 where our package is 1.1.18, so I started by freshening the packaging repo to build 1.1.29. Ironically, the build fails in the test suite with a probably easy to fix error that I just don't have time to work on today. I note that tox.ini in the upstream source seems to imply either pytest or nose can be used, but I'm not familiar enough with python test suites to immediately know if this is just left-over boilerplate, or if moving to pytest would be as simple as changing the tox.ini content? If someone else who understands python test suites better than I do has time to patch rocketcea to use a supported test suite and get 1.1.29 to build to completion, I'd love to have that help. Regards, Bdale signature.asc Description: PGP signature
Bug#967685: GTK 4 support now shipping
The promised librnd update to include GTK 4 support happened, and so when the time comes, we can fairly simply turn off GTK 2 and turn on GTK 4. I see no reason to do that until/unless GTK 2 removal from Debian is actually scheduled, however. Bdale
Bug#1017103: [Pkg-electronics-devel] Bug#1017103: Provide transition package for geda-gaf
Moritz Muehlenhoff writes: > Source: lepton-eda > Version: 1.9.18-1 > Severity: wishlist > > geda-gaf has been removed from the archive. In #1008700 it was mentioned > that lepton-eda is a sufficient replacement, so it could provide a > transition package to help existing geda-gaf users. How do you think we should implement that? I'm happy to patch the Debian packaging of lepton-eda to make something useful happen, just not sure what makes sense? Bdale signature.asc Description: PGP signature
Bug#1011549: openrocket needs newer jogl
tony mancill writes: > In other words, it seems to be non-free blobs all the way down. Sadly, I keep running into this in the Java world. > If the patched version of jogl is required for openrocket, we would need > someone to come up with some DFSG sources for the patches. I'll talk to openrocket upstream about it and see if I can't get some clarification about what we actually need and a pointer to the relevant source code. Bdale signature.asc Description: PGP signature
Bug#1011549: openrocket needs newer jogl
Package: libjogl2-java Version: 2.3.2+dfsg-9 I'm working on re-packaging openrocket so that it can go back into Debian main. A big part of the work is eliding all the embedded class library jar files and replacing those with Debian library packages. One of the class libraries is jogl, for which openrocket apparently needs jogl 2.4 with patches applied by Sibo: https://github.com/openrocket/openrocket/issues/1156 https://github.com/openrocket/openrocket/pull/1157 Is there any chance we could freshen the Debian package? I see that jogamp.org still shows 2.3.2 as the most recent "stable" release, but that's about 7 years old. I'm linking against the 2.3.2 package now, and the core of openrocket is working ok, but none of the 3d rendering features will work until we get to a fresher jogl version. Regards, Bdale signature.asc Description: PGP signature
Bug#1008700: [Pkg-electronics-devel] Bug#1008700: Should geda-gaf be removed?
Moritz Mühlenhoff writes: > If lepton-eda is a sufficient drop-in replacement for existing geda-gaf > users, lepton could provide a geda-gaf transition package for the bookworm > release? I can file a bug against lepton-eda when geda-gaf has been > removed. Yes, we could certainly do that. Bdale signature.asc Description: PGP signature
Bug#1008700: [Pkg-electronics-devel] Bug#1008700: Should geda-gaf be removed?
Moritz Muehlenhoff writes: > Source: geda-gaf > Version: 1:1.8.2-11 > Severity: serious > > Your package came up as a candidate for removal from Debian: For the record, I've previously indicated that I consider lepton-eda a complete replacement for geda-gaf in Debian. It was forked some years ago, is actively maintained, and still reads existing geda-gaf designs and library files perfectly. I contribute to lepton-eda upstream, and actively maintain the lepton-eda package in Debian. I do wonder if there's some action we can/should take when removing geda-gaf to ease the transition for existing users of the package to lepton-eda? Perhaps replace the package content with dependency information causing the replacement to be more or less automatic on upgrades? [shrug] Bdale signature.asc Description: PGP signature
Bug#1007613: pforth: please consider upgrading to 3.0 source format
Lucas Nussbaum writes: > Source: pforth > Version: 21-12 > > This package is among the few (1.9%) that still use source format 1.0 in > bookworm. As indicated in #791946, I'm waiting for a new upstream release. When it emerges, the Debian pforth package will be updated. There's really no point in considering changing the source package format until there. Bdale signature.asc Description: PGP signature
Bug#1006227: please resolve lepton-eda s390x out of date in testing
Package: ftp.debian.org Hi. In response to bug 1006172, it appears the best fix for now would be to arrange for the lepton-eda 1.9.16-3 binaries for s390x to be removed from the archive. I'd be fine with either the s390x binaries only being removed, or the complete removal of 1.9.16-3 from the archive. The goal is to allow 1.9.17-2 to promote to testing without waiting for the s390x porters to figure out what's wrong in the guile port that's triggering test suite errors in a package that's unlikely to ever be used on s390x in any case. Regards, Bdale signature.asc Description: PGP signature
Bug#1006172: [Pkg-electronics-devel] Bug#1006172: src:lepton-eda: fails to migrate to testing for too long: FTBFS on s390x
Paul Gevers writes: > Your package fails to build on s390x where it build successfully in > the past. I've X-Debbugs-CC-ed the s390x porters to help you > understand why only this architecture is affected. It's hard to imagine anyone actually trying to use lepton-eda on s390x. If the porting team for that architecture wants to figure this out, that's great, but I'd personally be completely comfortable having the s390x binaries removed from the archive to allow fresher lepton-eda to migrate to testing. Bdale signature.asc Description: PGP signature
Bug#1002252: [Pkg-electronics-devel] Bug#1002252: pcb-rnd: FTBFS: dh_auto_test: error: make -j4 test VERBOSE=1 returned exit code 2
severity 1002252 important thanks Lucas Nussbaum writes: > During a rebuild of all packages in sid, your package failed to build > on amd64. It looks like noise from the latest librnd version is causing a pcb-rnd test failure. There is no operational bug in either the library or the application pcb-rnd. Upstream reports this is already fixed in their tree, and will apparently be in the next librnd release due in March. Upstream really hates when I pull patches out of his tree to make off-cycle updates, so unless this actually causes someone an operational problem with the existing binary packages, my intent is to just package the next librnd release as soon as possible. Bdale signature.asc Description: PGP signature
Bug#1002479: precompile scheme code for faster start times
Package: lepton-eda Severity: wishlist There is some upstream support for pre-compiling the scheme code and including the resulting files in the binary package. Getting it to actually work in a Debian package will take more work than I'm currently motivated to undertake. Still .. it would be nice to do some day. Bdale
Bug#1002050: dh-addon dependency test false positive
Package: lintian Version: 2.114.0 I'm getting the error: E: lepton-eda source: missing-build-dependency-for-dh-addon autoreconf => dh-autoreconf | debhelper (>= 9.20160403~) | debhelper-compat [debian/rules] on a package that has Build-Depends: debhelper (>= 13) in the control file. This seems like a bug? Bdale
Bug#999738: runtime deps on -dev library symlinks not caught
Felix Lechner writes:
> Do you have the output of 'readelf --all --wide' [1] for one of those
> binaries?
The elf library binaries delivered by the package actually look fine.
Digging further, it appears the problem cases are all in guile code,
where the function dynamic-link is handed a token like 'libglib-2.0':
(define libglib (dynamic-link "libglib-2.0"))
This guile code gets "compiled" on the first invocation of the
application and cached in ~/.cache/guile. The problem is that at
runtime, that function call results in an attempt to load
'libglib-2.0.so' which fails if the -dev package isn't installed.
I'm fixing those with Makefile.am changes like:
-LIBGLIB=libglib-2.0
+LIBGLIB := $(shell /sbin/ldconfig -p | awk '/libglib-2.0.so\./ { print $$1
}')
That changes the guile code to look like:
(define libglib (dynamic-link "libglib-2.0.so.0"))
which works as desired at runtime, since that symlink is provided by the
binary library package.
So .. I'm not sure how good the return on investment of trying to add a
test for this in lintian would be. Talking to upstream about it, the
approach I'm using in Makefile.am seems credible and they make just take
that in. There's no indication the dynamic-link function in guile is
going to get any "smarter", so Makefile.am is probably the right place
to fix the problem.
> Your condition involves sonames that I believe are customarily
> provided by links in '-dev' installables instead of regular shared
> library packages.
Exactly.
> What do you think, please? Thanks!
I don't know if lintian already tries to parse any scheme source. If
not, just close this as I don't think it's worth chasing. If it does,
we could perhaps add a test for the dynamic-link function being handed a
token without '.so.0' in it, or something?
Bdale
signature.asc
Description: PGP signature
Bug#999738: runtime deps on -dev library symlinks not caught
Package: lintian Severity: wishlist I've had a couple bugs recently, including 999699, where upstream Makefile.am content has resulted in binaries delivered in a .deb having a run-time dependency on the symlinks provided in the library -dev package instead of the ".0" version of those files provided in the actual library packages. It would be nice if lintian were to notice and warn about these cases, particularly if the -dev package isn't explicitly specified as a binary package dependency (as it probably shouldn't be in most cases?). Bdale signature.asc Description: PGP signature
Bug#999699: [Pkg-electronics-devel] Bug#999699: Start of lepton-schematic failed
tags 999699 +pending thanks Bernhard writes: > The start of lepton-schematic failed because of missing > libglib-2.0.so. The underlying problem is with the way the lepton-eda developers refer to shared libs in the Makefile.am content in scheme library build directories. The side effect is that the binary looks for the name of the library as presented in the -dev package, not the actual runtime binary library. I'd already found and fixed a couple such bugs, but upstream hasn't (yet?) changed their approach so I'm carrying the patches along for now. It's hard for me to catch these before upload since I always tend to have the dev libs installed on my laptop which allows the binaries to work here. Sorry about that! In the short term, you can install libglib2.0-dev and things will work. For the longer term, I've added another patch to to the lepton-eda Debian package build and will report this case upstream. Look for 1.9.16-2 to be uploaded shortly. Bdale signature.asc Description: PGP signature
Bug#791946: Please support ARM64 (new upstream works)
Martin Michlmayr writes: > pforth is not enabled for arm64 in debian/control. Using upstream > version V27, pforth works on arm64. I recently traded emails with upstream, because even V27 is quite old and there's much more reason work in upstream revision control. He says a new upstream release is in the works, and was energized by my expression of interest in updating the Debian package. So .. I'll plan to update the package, bringing it up to current Debian standards and so forth as soon as he makes a new release. Bdale signature.asc Description: PGP signature
Bug#997871: Re : Bug#997871: debian-history: A few paragraphs are not translated
nicolas.patr...@gmail.com writes: > Le 26/10/2021 20:17:29, Bdale Garbee a écrit : > >> My French language skills are insufficient to work on this myself. >> I'll be happy to merge credible patches if/when they appear from others. > > OK, I’ll read again the history and propose fixes. > In which format do you want them? diff/patch on HTML? Or just my > translations? Patches to the package source, or replacement .po files, are the easiest for me to handle. Note, if you aren't already aware, that there is a fairly well organized effort for translating things in Debian. Here are a couple starting points for learning more: https://www.debian.org/doc/manuals/developers-reference/l10n.en.html https://wiki.debian.org/L10n Bdale signature.asc Description: PGP signature
Bug#997871: debian-history: A few paragraphs are not translated
Nicolas Patrois writes: > Package: debian-history > Version: 2.26 > Severity: normal > Tags: l10n > > Dear Maintainer, > > A few paragraphs in the French pages are not translated. > These pages are mostly in French excepted one or two paragraphs. > > Maybe it’s the same in other languages. My French language skills are insufficient to work on this myself. I'll be happy to merge credible patches if/when they appear from others. Bdale signature.asc Description: PGP signature
Bug#716143: working as intended
tags 716143 +wontfix thanks The upstream author of pforth has weighed in and believes that crashing in this way means that pforth is working as intended. I'll leave the bug open so it isn't duplicated in the future, but mark it wontfix as I don't intend to change anything because of it. Bdale
Bug#994921: [Pkg-electronics-devel] Bug#994921: librnd3-dev: missing Breaks+Replaces: librnd-dev
Andreas Beckmann writes:
> I'm not sure whether it would be helpful, but a (versioned?)
> Provides: librnd-dev (= ${binary:Version})
> could ease upgrading from librnd-dev to librnd3-dev.
Yes, that makes sense.
> BTW, why has the -dev package been renamed from librnd-dev to librnd3-dev?
> It's not for co-installability of new and old versions since librnd-dev
> was removed from sid.
Upstream anticipates that it will be useful to have librnd3-dev and
librnd4-dev able to co-exist once librnd4 is released in the future, so
recommended I change the package name to avoid future confusion.
Bdale
signature.asc
Description: PGP signature
Bug#990384: ITP: librnd -- Ringdove 2D CAD library framework
Package: wnpp Severity: wishlist Owner: Bdale Garbee X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: librnd Version : 3.0.0 Upstream Author : Tibor Palinkas * URL : http://repo.hu/projects/pcb-rnd * License : GPL Programming Lang: C Description : Ringdove 2D CAD library framework The upstream developer of the pcb-rnd, the printed circuit board tool in the "Ringdove" tool suite, has re-factored the code to deliver a standalone shared library containing many core functions, which will also be used by additional applications soon to be released. As the primary maintainer of pcb-rnd within the Debian Electronics team, I anticipate maintaining this package and others to come in the Ringdove suite similarly to the way pcb-rnd is currently maintained. Bdale
Bug#984609: openrocket: uninstallable: depends on no longer available openjdk-8-jre
Andreas Beckmann writes: > Package: openrocket > Version: 15.03.6 > Severity: serious > User: debian...@lists.debian.org > Usertags: piuparts > > Hi, > > during a test with piuparts I noticed your package is no longer > installable in sid: > > The following packages have unmet dependencies: >openrocket : Depends: openjdk-8-jre but it is not installable Known, and the package has already been excluded from testing. I'm working on re-packaging from upstream unreleased source for future inclusion in Debian main. There's really no solution for making the current jar installer work without pulling the openjdk-8-jre in. Doing that from oldstable will continue to work for quite a while, so this installer isn't entirely useless in the interim until I can complete re-packaging for main. Will leave the bug open until then. Bdale signature.asc Description: PGP signature
Bug#192522: sudo: should validate sudoers on upgrade and abort if incompatible
Marc Haber writes: > I am therefore reluctant to implement this at the moment. FYI, I never found an acceptable solution to this problem, and chose to leave the bug open to remind myself and anyone searching for help that this *could* happen. It might be better to move this into a README.Debian clause or something and close the bug with no further action taken? Bdale signature.asc Description: PGP signature
Bug#982160: sudo does not honour "NOPASSWD" directive
Wolfgang Sourdeau writes: > [myuser] ALL=(ALL) NOPASSWD: ALL Try [myuser] ALL=(ALL:ALL) NOPASSWD: ALL Bdale signature.asc Description: PGP signature
Bug#981040: RM: pcb-rnd [s390x] -- ANAIS; architecture specific bug upstream
Package: ftp.debian.org Severity: normal Please remove s390x binary packages built from pcb-rnd version 2.3.0-3 from the archive. The newer version 2.3.1-1 is failing to build on s390x due to an architecture-specific bug in floating point math handling acknowledged by upstream. Unfortunately, he says he won't be able to fix this until a future pcb-rnd release. In the meantime, since this package is unlikely to be used by s390x port users, and the new version has functionality important to users of the package on other architectures, upstream recommends we just flush previous binaries and allow versions 2.3.1-1 and beyond to promote to testing and eventually stable release. Regards, Bdale
Bug#979649: libvirt-guests.sh shouldn't whine about not being used
Package: libvirt-daemon Version: 6.9.0-1+b2 Severity: normal The libvirt-guests.sh script outputs the text "libvirt-guests is configured not to start any guests on boot" on every system boot if ON_BOOT is set to anything other than "start". This is confusing to inexperienced systems admins who think it means something is wrong, and serves no useful purpose. It is, at best annoying to an experienced systems admin who has made the choice to not use this script. Please either remove this output entirely, or provide some additional mechanism in the /etc/default/libvirt-guests file to shut it up! Bdale -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-4-amd64 (SMP w/8 CPU threads) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libvirt-daemon depends on: ii libblkid1 2.36.1-4 ii libc6 2.31-7 ii libcap-ng0 0.7.9-2.2+b1 ii libdevmapper1.02.1 2:1.02.173-1 ii libfuse22.9.9-3 ii libgcc-s1 10.2.1-3 ii libglib2.0-02.66.4-1 ii libnetcf1 1:0.2.8-1.1 ii libparted2 3.3-4 ii libpcap0.8 1.10.0-1 ii libpciaccess0 0.16-1 ii libselinux1 3.1-2+b2 ii libudev1247.2-4 ii libvirt-daemon-driver-qemu 6.9.0-1+b2 ii libvirt06.9.0-1+b2 ii libxml2 2.9.10+dfsg-6.3+b1 Versions of packages libvirt-daemon recommends: pn libvirt-daemon-driver-lxc pn libvirt-daemon-driver-vbox pn libvirt-daemon-driver-xen ii libxml2-utils 2.9.10+dfsg-6.3+b1 ii netcat-openbsd 1.217-3 ii qemu-system-x86 [qemu-kvm] 1:5.2+dfsg-3 Versions of packages libvirt-daemon suggests: pn libvirt-daemon-driver-storage-gluster pn libvirt-daemon-driver-storage-rbd pn libvirt-daemon-driver-storage-zfs ii libvirt-daemon-system 6.9.0-1+b2 pn numad -- no debconf information
Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?
Russ Allbery writes: > I assumed that if option B won, some > maintainers would drop init scripts, and therefore if folks wanted to > maintain a set of working init scripts, they'd need to look at different > options than ensuring they were incorporated into each package. I agree, this was my sense of what B meant at the time, too. Bdale signature.asc Description: PGP signature
Bug#977595: [Pkg-electronics-devel] Bug#977595: lepton-eda/lepton-attrib and lepton-eda/lepton-schematic can't find libgtk-x11-2.0
severity 977595 serious thanks Vanessa Dannenberg writes: Hi Vanessa! > Package: lepton-eda > Version: 1.9.13-1 > Severity: grave > > [ This is a fresh install of Bullseye/testing, from a net-install > image fetched just today] I couldn't duplicate your problem on my "unstable" development system, so I just installed a VM client using today's "Bullseye Alpha 3" netinst image for amd64 to test with. On that system, I was indeed able to duplicate your failure. > However, when I try to run lepton-schematic, it appears to compile > something, and then fails. Yes. When first invoked, the lepton-* applications want to compile the guile code. The results are cached so that future invocations don't have to replicate that, and are very fast. There's supposedly a way to force compilation of at least some of the guile code at package build time, but I haven't tried that yet. And that's the source of the problem. It turns out that compiling the guile code requires that libgtk2.0-dev is installed on the system. That's unfortunate since it pulls in a huge chain of dependencies, but it means that the short-term workaround for you is therefore simply: apt install libgtk2.0-dev The next time you try to run any of the lepton-* applications after doing that, it should work fine. If not, please let me know! In the meantime, I'll leave this bug open and try to figure out how to eliminate this dependency at run-time, perhaps by turning on the guile pre-compile support if I can figure it out. I will drop the severity to serious, keeping it release-critical but not implying really bad behavior like data loss or a security hole. Thanks very much for reporting this! Regards, Bdale signature.asc Description: PGP signature
Bug#976304: RFA: gzip -- GNU compression utilities
Package: wnpp Severity: normal I took over the Debian gzip package on 2 December 1995, which means that as of today, I've taken care of it for 25 years! The package is in good shape, though a number of bugs have accumulated over the years that I have neither the time nor motivation remaining to address... so, like some other packages I've maintained for a long time, I've decided to offer the gzip package for adoption. Because this is a 'required' package, and has a special variant needed for at least one Debian installation method, I would like to suggest that anyone considering taking over the package have a look at the current sources and open bug reports first, then reach out to me for a conversation before making a commitment to take over the package. Bdale
Bug#976244: RFA: sudo -- Provide limited super user privileges to specific users
Package: wnpp Severity: normal I took over the sudo package in August of 1996, and have maintained it since then. The package is in pretty good condition, with very reliable core functionality. Upstream is active and responds promptly to concerns. Despite this, there are a significant number of bugs open against the package, a fair number of which are related to the LDAP interface or other features I don't use, and just don't have the time, facilities, and/or motivation to work on. So, I think that after nearly a quarter century taking care of sudo in Debian, it's time someone else took over the package. Because this package is more or less "essential" to many users despite being marked as 'optional' in our packaging system, I'd like to suggest anyone considering taking it on look over the package, review the open bug list, and then reach out to me for some conversation before making a committment to take it over. Bdale
Bug#965098: geda-gaf orphaned
In light of Kai-Martin Knaak's comments here, I won't push harder for geda-gaf to be removed from Debian. However, since I have no intention of doing more work on it myself, I just filed bug #975985 marking geda-gaf as orphaned. Bdale
Bug#975985: O: geda-gaf
Package: wnpp Severity: normal I personally don't use geda-gaf any longer, and do not plan to do any more work on it. From the discussion in #965098, it seems not all users are happy just moving to lepton-eda. I'm filing this bug to ensure that if the package remains in Debian, it is at least clear that I have no intention of doing more work on it myself. Bdale
Bug#975938: ITP: jboss-vfs -- JBoss Virtual File System
Package: wnpp Severity: wishlist Owner: Bdale Garbee X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: jboss-vfs Version : 3.2.15.Final Upstream Author : JBoss, A division of Red Hat, Inc. * url : http://www.jboss.org * License : Apache-2.0 Programming Lang: Java Description : JBoss Virtual File System This package delivers the JBoss VFS libraries. A much earlier version was once included in Debian but dropped due to lack of use. I'm re-packaging a modern version with help from Sudip Mukherjee because it's a dependency for annotation-detector, which is a dependency for openrocket, which I'm trying to get back into main instead of being a jar-installer package in contrib.
Bug#975404: ITP: annotation-detector -- scan class path for annotated classes, methods, or instance variables
Package: wnpp Severity: wishlist Owner: Bdale Garbee X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: annotation-detector Version : 3.0.5 Upstream Author : XIAM Solutions B.V. (http://www.xiam.nl) * URL : https://github.com/rmuller/infomas-asl * License : Apache Programming Lang: Java Description : scan class path for annotated classes, methods, or instance variables This library can be used to scan (part of) the class path for annotated classes, methods or instance variables. Main advantages of this library compared with similar solutions are: light weight (no dependencies, simple API, 20 kb jar file) and very fast (fastest annotation detection library as far as I know). I'm packaging this because it's a build dependency for openrocket, which I would like to move back from being a "jar installer" in contrib to a real build from source in main. Bdale
Bug#974811: ITP: pyqt-distutils -- distutils extension to work with PyQt applications and UI files
Package: wnpp Severity: wishlist Owner: Bdale Garbee X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: pyqt-distutils Version : 0.7.3 Upstream Author : Colin Duquesnoy * URL : https://github.com/ColinDuquesnoy/pyqt_distutils * License : MIT Programming Lang: Python Description : distutils extension to work with PyQt applications and UI files The goal of this tiny library is to help you write PyQt application in a pythonic way, using setup.py to build the Qt designer Ui files. This works with PyQt4, PyQt5 and PySide (tested with python3 only). I'm willing to package this because it's a build dependency for openMotor, which I'm working on packaging. Bdale
Bug#973844: RFA: tar
Janos LENART writes: > I would like to adopt & maintain tar. I am using some of the 'newer' > features at many sites that the current bugs are about, like remote > archives, zstd and incremental; also well versed in C. I have been a DD > since 2000. > > Looking at the list of bugs I am thinking most of them should be forwarded > to upstream. There are some low hanging fruits like #892273, and there are > good few that will be wontfix like #310323 . > > Can I fix for example #892273 and upload a new version, or did you have > something else in mind? Sounds fine. Thanks for your interest! > Am I assuming correctly that https://salsa.debian.org/debian/tar.git is up > to date? :-) Yes. I added a debian/README.source documenting the repo branch structure and how to integrate a new upstream release, and pushed to ensure the salsa repo is up to date. Please feel free to ask if you need anything else. Bdale signature.asc Description: PGP signature
Bug#974161: ITP: openmotor -- internal ballistics simulator for rocket motor experimenters
Package: wnpp Severity: wishlist Owner: Bdale Garbee X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: openmotor Version : 0.4.0 Upstream Author : https://github.com/reilleya * URL : https://github.com/reilleya/openMotor * License : GPL Programming Lang: Python Description : internal ballistics simulator for rocket motor exper openMotor is an open-source internal ballistics simulator for rocket motor experimenters. The software produces estimates of a rocket motor's chamber pressure and thrust based on input such as propellant properties and grain geometry. It uses the Fast Marching Method to determine how a propellant grain regresses, which allows the use of arbitrary core geometries. Current Features: * Metric and imperial units * Support for common grain geometries such as BATES, Finocyl, Star and more * Loading custom grain geometry from DXF files * A propellant editor that allows the user to enter the properties of as many propellants as they wish * The grain editor displays how a grain will regress to cut down on the guesswork involved in tweaking geometry * ENG file exporting * Burnsim importing and exporting * A UI that supports saving and loading designs along with undo and redo. Planned Features: * Erosivity simulation * Detailed output of every calculated parameter at any time and position along the motor
Bug#974160: ITP: scikit-fmm -- Python module which implements the fast marching method
Package: wnpp Severity: wishlist Owner: Bdale Garbee X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: scikit-fmm Version : 2019.1.30 Upstream Author : The scikit-fmm team * URL : http://packages.python.org/scikit-fmm * License : BSD Programming Lang: Python, C/C++ Description : Python module which implements the fast marching method Python module which implements the fast marching method. The fast marching method is used to model the evolution of boundaries and interfaces in a variety of application areas. More specifically, the fast marching method is a numerical technique for finding approximate solutions to boundary value problems of the Eikonal equation: F(x) | grad T(x) | = 1 Typically, such a problem describes the evolution of a closed curve as a function of time T with speed F(x)>0 in the normal direction at a point x on the curve. The speed function is specified, and the time at which the contour crosses a point x is obtained by solving the equation. scikit-fmm is a simple module which provides functions to calculate the signed distance and travel time to an interface described by the zero contour of the input array phi. Petter Reinholdtsen and I are collaborating on packaging this as it is a build dependency for the openmotor package I am also working on. Bdale
Bug#974156: ITP: ezdxf -- Python package to create and modify DXF drawings
Package: wnpp Severity: wishlist Owner: Bdale Garbee X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: ezdxf Version : 0.14.2 Upstream Author : Manfred Moitzi * URL : https://ezdxf.mozman.at * License : MIT Programming Lang: Python Description : Python package to create and modify DXF drawings Python package to create and modify DXF drawings, independent from the DXF version. You can open/save every DXF file without losing any content (except comments). Unknown tags in the DXF file will be ignored but preserved for saving. With this behavior it is possible to open also DXF drawings that contains data from 3rd party applications. Petter Reinholdtsen and I are collaborating to package this, which is a dependency for the openmotor package I'm also working on. Bdale
Bug#973844: RFA: tar -- GNU version of the tar archiving utility
Package: wnpp After maintaining the Debian package of tar since 3 December 1995 (nearly a quarter century!), I've decided it's time to let someone else take over. The Debian tar package is generally in very good shape, and does all the routine things quite reliably. However, like many GNU project versions of well-known Unix applications, tar has accreted a massive number of optional features over the years... very few of which I actually use. And these are what many of the open bugs against the package are about. Also, as is the case with some other GNU applications, tar has documentation under the FDL with invariant sections, so as a matter of Debian policy the docs are distributed in non-free. This complicates the packaging process somewhat, though I have a well-documented process for ingesting a new upstream release into the packaging repository and rippling updates into the various required branches. If you want to jump in, I suggest you start by taking a look at the current list of open bugs, find one or two to fix, and then reach out to me for some discussion. As tar is an essential package, taking it on does carry an extra measure of responsibility. Regards, Bdale signature.asc Description: PGP signature
Bug#972831: tar: produces incorrect TAR+zstd archive when creating archive remotely
Laurent Bonnaud writes: > $ tar --zstd -cvf localhost:foo.tar.zst foo I took a quick look and the problem is with the use of localhost: in the filename, it appears to be unrelated to the compression algorithm chosen. I don't have time to chase this further today. Bdale signature.asc Description: PGP signature
Bug#970242: debian-history: The current DPL info is outdated, please update
Boyuan Yang writes: > Let me know if it's okay for me to make a quick 0-day NMU and fix this > info Yes. Bdale signature.asc Description: PGP signature
Bug#970198: src:openrocket: fails to migrate to testing for too long: Depends on openjdk-8 which is blocked from testing
Paul Gevers writes: > Your package Depends on openjdk-8, which isn't supposed to be used in > testing since beginning 2019. FYI, this dependency will remain until/unless upstream makes a new release, and is still present in the version in unstable. Bdale signature.asc Description: PGP signature
Bug#957019: atlc: diff for NMU version 4.6.1-2.1
Sudip Mukherjee writes: > Control: tags 957019 + patch > Control: tags 957019 + pending > > Dear maintainer, > > I've prepared an NMU for atlc (versioned as 4.6.1-2.1) and > uploaded it to DELAYED/5. Please feel free to tell me if I > should cancel it. Thank you! Bdale signature.asc Description: PGP signature
Bug#965098: please remove geda-gaf from the archive
Moritz Mühlenhoff writes: > On Thu, Jul 16, 2020 at 08:47:39AM -0700, Sean Whitton wrote: >> > There are two reverse dependencies on geda-gaf, gspiceui, and >> > contrib/easyspice. Both appear to be maintained by Gudjon >> > I. Gudjonsson, who I will CC. >> >> Please remove the moreinfo tag from this bug once these packages have >> been removed or updated such that there are no more rdeps. > > I've filed #967915 and g#967916 against gspiceui and easyspice. Thank you. Bdale signature.asc Description: PGP signature
Bug#949519:
tags 949519 + help thanks I do not currently have the facilities or the motivation to try and debug LDAP issues in sudo. Happy to merge a patch if someone else figures out what's going wrong here. Bdale signature.asc Description: PGP signature
Bug#885195: [Pkg-electronics-devel] Bug#885195: Bug#885195: geda-gaf: please migrate to guile-2.2
Rob Browning writes: > Bdale Garbee writes: > >> However, I see little chance of geda-gaf upstream working on the things >> needed to keep it viable in Debian any time soon, and with lepton-eda in >> my mind a complete replacement that still works with the same file >> formats, etc, I see no reason to go nuts trying to make geda-gaf better. >> >> I'll file a removal request for geda-gaf. > > OK, thanks for the help. See #965098. Bdale signature.asc Description: PGP signature
Bug#965098: please remove geda-gaf from the archive
Package: ftp.debian.org I'm a member of the Debian Electronics team, and have been one of the maintainers of Debian's geda-gaf package for the last few years. The geda-gaf package is holding back guile-2.0 removal, and I see little chance that upstream will care about this any time soon. There's a newer upstream release than what's in Debian, and it still hard depends on guile-2.0. For users, the lepton-eda package which is well maintained upstream and in Debian is a complete replacement, with no change in file formats so existing designs can just continue to be worked on. The current lepton-eda package supports guile-2.2, and I understand guile-3.0 support will be included in the next upstream version. There are two reverse dependencies on geda-gaf, gspiceui, and contrib/easyspice. Both appear to be maintained by Gudjon I. Gudjonsson, who I will CC. It looks like the last gspiceui upstream release was in late 2018, and the only reason it depends on geda-gaf is that it wants to use gnetlist to import schematic data from gschem. Updating that to use lepton-netlist to import schematic data from lepton-schematic should be a pretty simple search and replace operation if keeping gspiceui seems worthwhile (I don't know, I've never used it). The situation with easyspice seems similar, and it can probably be made to work with lepton-eda just as easily. However, since it's in contrib and not main, I'm not particularly concerned about what happens to it. Bottom line, I think it's time we remove geda-gaf from the archive, and focus the attention of geda-gaf users towards lepton-eda as a replacement. Bdale signature.asc Description: PGP signature
Bug#885195: [Pkg-electronics-devel] Bug#885195: Bug#885195: geda-gaf: please migrate to guile-2.2
Rob Browning writes: > Bdale Garbee writes: > >> I'm not interested in maintaining pcb any more. > > Does that mean geda-gaf etc? If so might it make sense for you (or > who?) to file a removal request, i.e. ROM or similar? Sorry, you make a good point, geda-gaf and pcb aren't the same thing. While I no longer use either (choosing to use the forks lepton-eda and pcb-rnd instead), there's no immediate need to shove pcb out of the archive. However, I see little chance of geda-gaf upstream working on the things needed to keep it viable in Debian any time soon, and with lepton-eda in my mind a complete replacement that still works with the same file formats, etc, I see no reason to go nuts trying to make geda-gaf better. I'll file a removal request for geda-gaf. Bdale signature.asc Description: PGP signature
Bug#964922: sudo: segmentation fault when include directive is active in /etc/sudoers
tags 964922 +pending thanks Thorsten Glaser writes: > On Sun, 12 Jul 2020, Bdale Garbee wrote: > >> However, since your but report caused *me* to go read that and realize @ >> is now preferred to # for that directive, I'm updating the default >> sudoers file for Debian to use @. Perhaps that will help reduce this >> particular form of confusion in the future. > > The file now reads: > > | # See sudoers(5) for more information on "#include" directives: > | > | @includedir /etc/sudoers.d > > Maybe you want to replace the other ‘#’ as well? Good point. In my repo for the next upload. Bdale signature.asc Description: PGP signature
Bug#885195: [Pkg-electronics-devel] Bug#885195: Bug#885195: geda-gaf: please migrate to guile-2.2
I'm not interested in maintaining pcb any more. Bdale On July 13, 2020 7:04:01 PM MDT, Rob Browning wrote: >Bdale Garbee writes: > >> So... while I'm sure gEDA could be "saved" in Debian with enough >effort, >> I just don't see the point, and won't put any time or attention on it >> myself. > >I'd suggest we should do something "soonish". This is the last package >holding guile-2.0 in testing, and I'd *really* like to be able to >finish >the guile-2.0 removal. > >For what it's worth, I thought I'd see how hard it might be to update >to >guile-3.0, and the attached (very primitive/incomplete) diff does get >the current package to build and pass all but one of the tests here >(assuming that wasn't a short-circuit and there are more tests after >that). > >However, unless someone's interested in maintaining the package, >pursuing guile-3.0 support, upgrading to 1.10, etc. Perhaps it's best >to file for removal now. We can always reintroduce it later, if the >situation improves. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#885195: [Pkg-electronics-devel] Bug#885195: Bug#885195: geda-gaf: please migrate to guile-2.2
أحمد المحمودي writes: > On Mon, Apr 27, 2020 at 08:48:59PM -0600, Bdale Garbee wrote: >> As far as I'm concerned, you can feel free to remove geda-gaf from Debian. >> >> I'm personally quite happily living on the fork that I've packaged of >> lepton-eda. Lepton-eda is very actively maintained and improved, and >> while there's a recent new release of geda-gaf, I'm not likely to spend >> any more time working on the geda-gaf packaging. > ---end quoted text--- > > Aren't there any features in gEDA 1.10 that aren't present in Lepton > EDA? That's a reasonable question. I haven't looked much at gEDA since moving to lepton-eda, so I'm probably not the right person to answer this question. However... The lepton-eda fork came into existence at least in part due to the messy integration of xorn (python extension language support) into gEDA. So, almost by definition, anything related to python as an extension language exists in gEDA but not in lepton-eda. By contrast, the lepton-eda code started with a fork of gEDA just before the xorn merge, and has doubled-down since on using guile for as much as possible. I'm personally happy coding in guile and contributed a tEDAx export module to lepton-eda so that I can easily use it with pcb-rnd. From a practical standpoint, 1.10 is the first new gEDA release in a very long time, and it still build depends on guile-2.0 (caring for guile clearly isn't a priority). On the lepton-eda side, the core team is quite active (new commits in the git repo almost every day), has made multiple stable releases since I started packaging it in August of 2018 (1.9.4 to 1.9.10), and they cheerfully did the work to move from guile-2.0 to 2.2 when I pointed out this was going to become an issue for Debian. As a *user*, I'm happily using lepton-eda almost daily, for all of my circuit board design work. That includes ongoing maintenance and support of designs that I started with geda-gaf. So... while I'm sure gEDA could be "saved" in Debian with enough effort, I just don't see the point, and won't put any time or attention on it myself. Bdale signature.asc Description: PGP signature
Bug#885195: [Pkg-electronics-devel] Bug#885195: geda-gaf: please migrate to guile-2.2
Rob Browning writes: > Please try to migrate soon, and at this point, to guile-3.0 if possible. > Otherwise we might need to consider removing the package from Debian. As far as I'm concerned, you can feel free to remove geda-gaf from Debian. I'm personally quite happily living on the fork that I've packaged of lepton-eda. Lepton-eda is very actively maintained and improved, and while there's a recent new release of geda-gaf, I'm not likely to spend any more time working on the geda-gaf packaging. > Sometimes it's sufficient to just update the build dependency from say > guile-2.0-dev to guile-3.0-dev and adjust some of the related versions > in configure.ac (or configure.in). This is absolutely not true for geda-gaf, the recent release still demands guile-2.0. If someone actually wants to fix geda-gaf to work with guile-2.2 or later, my suggestion would be to look at how lepton-eda fixed the scheme code in question. Bdale signature.asc Description: PGP signature
Bug#958402: sudo: A password is required for /usr/bin/uptime
l0f4r0 writes: > My journalctl indicates numerous alerts/1 like "sudo[XXX]: l0f4r0 : a > password is required ; TTY=unknown ; PWD=/home/l0f4r0 ; USER=root ; > COMMAND=/usr/bin/uptime". I've never seen this before, and can find no evidence of it on any of my stable servers running the same sudo version. > I can't be really sure this issue must be dealt by sudo itself but I > didn't manage to see another correlation with anything else during my > investigation. I'm afraid I have no idea how to help. Bdale signature.asc Description: PGP signature
Bug#931532: could use help on this
tags 931532 +needhelp thanks I don't have any easy way to debug LDAP issues in sudo. If someone else has time to chase this down and tell me what's wrong, that'd be great. Bdale signature.asc Description: PGP signature
Bug#949419:
tags 949519 +needhelp thanks I don't have any easy way to debug LDAP issues. If someone else does and wants to chase this down and let me know where the problem is, that'd be great. Bdale signature.asc Description: PGP signature
Bug#469315: still need mailcap entries
It's a decade later, and various apps including emacs still make routine use of mailcap data. Any chance you could just deliver a mailcap file and save me the pain of having to drop entries on every machine I configure? Bdale
