retitle 1108930 ITP: libcsxcad -- C++ library to describe geometrical objects
and their physical or non-physical properties
thanks
Matthias Geiger writes:
> This library is a direct dependency for openEMS.
I'm already working on this, as part of the ITP for openEMS. It seemed
like a bother t
I note that openEMS was packaged at one point by the Debian Science
Team, but the last work was apparently in 2021 based on a previous
upstream release. The work I plan to do is re-packaging starting with
upstream released version 0.0.36, which itself may prove to be somewhat
out of date (22 Oct 2
retitle 1108752 ITP: openems -- electromagnetic field solver
thanks
I've been watching sporadic work on integrating openEMS with the Ringdove
suite, and am sufficiently interested in using that work someday to take a
whirl at packaging openEMS for Debian.
I've created https://salsa.debian.org/ele
-02 12:10:13.0 -0600
@@ -1,3 +1,9 @@
+libmawk (1.0.4-4) unstable; urgency=high
+
+ * fix parallel build race condition, closes: #1106399
+
+ -- Bdale Garbee Mon, 02 Jun 2025 12:10:13 -0600
+
libmawk (1.0.4-3) unstable; urgency=medium
* disable link time optimization per upstream
Package: ftp.debian.org
Severity: normal
Please remove pcb from the archive. Upstream is dead, and pcb-rnd is a
complete replacement including file format support for pcb designs with
an active upstream.
I posted about this in January 2025 with no response, we should remove
pcb before trixie re
Paul Gevers writes:
> This bug report has been automatically generated and has only been sent
> manually. If you have any comments with regards to the content or the
> process, please reach out to me.
I assumed that the closure of #1101065 would allow sch-rnd to be
promoted to testing, since t
Package: ftp.debian.org
The new upstream package of sch-rnd, which I maintain for Debian, fails
to build on i386 due to an odd failure in the test suite. The upstream
maintainer and I are working on it, but I'm not sure how long this may
take to resolve. Getting version 1.0.8 into testing is mor
Lucas Nussbaum writes:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
Thanks for letting me know. I've reported this upstream at
https://github.com/lepton-eda/lepton-eda/issues/1077
Bdale
signature.asc
Description: PGP signature
FYI.
I did a local build of the cairo 1.18.2-1 Debian package folding in the
595.patch, and am pleased to report it does completely fix the problems
printing from evince, et al, on my laptop.
Bdale
Package: openems
Version: 0.0.35+git20190103.6a75e98+dfsg.1-3.2
When I tried to install openems, I saw that apt wanted to remove freecad,
which is an unacceptable consequence for me. Before digging in too far, I
went to look at the upstream openems site and noticed that v0.0.36 is the
current ve
Santiago Vila writes:
> Package: src:pcb
> Version: 1:4.3.0-3
> Severity: serious
> Tags: ftbfs
>
> Dear maintainer:
>
> During a rebuild of all packages in unstable, your package failed to
> build:
Upstream for pcb is mostly inactive, and many users have moved to
pcb-rnd, which started as a for
Package: wnpp
Severity: wishlist
Owner: Bdale Garbee
X-Debbugs-Cc: debian-de...@lists.debian.org
Package name: openrocket
Version : 23.09
URL : https://openrocket.info
License : GPLv3+
Programming Lang: Java
Description : Model Rocket Simulator
Helmut Grohne writes:
> Source: openrocket
> Severity: serious
> Justification: grab attention of maintainer
> User: helm...@debian.org
> Usertags: sidremove
>
> Dear maintainer,
>
> I suggest removing openrocket from Debian
I agree.
Upstream now offers for download a 'fat' jar file that can be
Sure, I can apply your patch in the Debian cpmtools package, since it has been
accepted upstream. I try to avoid forks, but gaining quicker access to
something that is coming in upstream's next release seems good.
Bdale
On August 29, 2024 7:11:12 AM CDT, Jacob Nevins
wrote:
>I wrote:
>> So
Package: ftp.debian.org
I am both upstream and the Debian maintainer of p10cfgd. This program
is obsolete, completely irrelevant, and now just a waste of space in
Debian and its derivatives. Please remove it from unstable.
Additional information if the above isn't sufficient. Around 1990, a
co
Zarko Zivanov writes:
> Package: cpmtools
> Version: cpmtools_2.23-4_amd64
>
> I have previously used cpmtools_2.20 and had no problems. With the
> recent version from repository, I am getting garbage printed on screen
> when I try to list the contents of an IMG file (or, actually, many IMG
> fil
Adrian Bunk writes:
> librnd4t64 provides librnd4 only on the architectures
> where no ABI change was done for 64bit time_t.
I think this is a consequence of trying to ensure librnd4 is at version
4.2.0 or later, rather than just letting ${shlibs:Depends} do the right
thing.
Bdale
signature.
I just stumbled over this report in the BTS. Since I haven't been employed
by HP since late 2016, I no longer have any way to help here. I suggest just
closing this bug since there was evidence the software worked for others at
the time.
Bdale
Package: libgd-dev
Installing libgd-dev and then running 'pkg-config --cflags gdlib' yield the
error:
Package raqm was not found in the pkg-config search path.
Perhaps you should add the directory containing `raqm.pc'
to the PKG_CONFIG_PATH environment variable
Package 'raqm', required by
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 wi
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 mad
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
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 adde
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
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,
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
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
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
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 maintain
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 D
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 sign
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 s
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://
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
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
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 thi
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
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.
B
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
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
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 compatibili
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 e
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 wh
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 #10360
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
:
>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 abou
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 discerna
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.
B
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
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.
Sadl
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.
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 st
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,
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 appear
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
Descri
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 ).
>
>
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
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 th
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
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, sin
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/
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 unmainta
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
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
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 openroc
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
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.
Bdal
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
a
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
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
a
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 tea
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
applicatio
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
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
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
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 provid
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
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 releas
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
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 Fr
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
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?
> I
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
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:
>
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
Wolfgang Sourdeau writes:
> [myuser] ALL=(ALL) NOPASSWD: ALL
Try
[myuser] ALL=(ALL:ALL) NOPASSWD: ALL
Bdale
signature.asc
Description: PGP signature
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
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 w
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 se
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 sys
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 t
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 o
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
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 c
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
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
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
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 m
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
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
1 - 100 of 1128 matches
Mail list logo
