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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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]
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
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
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
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
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
:
>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
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.
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
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.
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.
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
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
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 docum
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
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 ).
>
&g
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
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.
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 th
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
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
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.
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
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
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
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
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
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
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
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
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
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 p
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
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?
>
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 fil
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.
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
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 D
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 ti
أحمد المحمودي 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
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
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
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
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
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
1 - 100 of 1101 matches
Mail list logo
