On 6/24/23 19:30, Daniel Baumann wrote:
On 6/24/23 19:03, Christian Grothoff wrote:
Do we know if there is anything else that replaces
libgamin in terms of functionality?
it's seems gamin has been abandoned quite some time ago already in
favour of using inotify.
maybe using libinotify from
Ah, it's the replacement for libfam, which is why the code only has
libfam. Makes sense. Do we know if there is anything else that replaces
libgamin in terms of functionality? If not, you could of course simply
ship doodle without doodled, but I would try to keep it working if
someone can
Hi Daniel,
I'm a bit confused where the build-depends comes from, as I don't even
know what gamin *is* or how doodle would come to depend upon it. Do you
have any idea _why_ we build-depend on it? I'm happy to fix the
dependency, but first I'd need to know where it comes from...
Best,
Package: cvs
Version: 2:1.12.13+real-28
Severity: important
X-Debbugs-Cc: groth...@gmail.com
Dear Maintainer,
After the latest Debian update (the new stable release),
CVS suddenly stopped to function completely for me.
First, I got an error message about 'rsh' not found (and indeed
there was
Package: recutils
Version: 1.8-1
Severity: normal
X-Debbugs-Cc: groth...@gmail.com
Dear Maintainer,
GNU Recutils 1.9 is available, fixing security vulnerabilities.
Please make an updated package available.
-- System Information:
Debian Release: 11.3
APT prefers stable-updates
APT policy:
Package: python3-sphinx
Version: 1.8.5-3
Severity: wishlist
Dear Maintainer,
The current version packaged in Debian is very outdated,
even in unstable. Please consider packaging the current
upstream release.
-- System Information:
Debian Release: 10.1
APT prefers stable
APT policy: (700,
Source: gnunet
Severity: wishlist
Dear Maintainer,
Just new release, please update to get bugfixes & feature enhancements.
Thanks!
Christian
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (650, 'testing'), (600, 'unstable')
Architecture: amd64 (x86_64)
"reproduced" bug, by accident. As the original reporter describes, there
was a libpam update in my recent history. As well as a full hard drive
(explaining the write failure). Re-running pam-auth-update resolved the
situation.
signature.asc
Description: OpenPGP digital signature
Hi!
MHD maintainer here. I'm not sure I understand how adding a new symbol
and merely deprecating an old one creates a "dependency hell". You're
free to continue to use the old symbol for now, and we have no plans to
remove it particularly soon. We are still binary backwards-compatible,
as
I'm seeing the same issue on my Linux powerbot 3.2.0-4-powerpc #1 Debian
3.2.57-3 ppc GNU/Linux.
The bug is fully reproducable, each time I run
# apt-get -f install
Reading package lists... Done
Building dependency tree
Reading state information... Done
Correcting dependencies... Done
The
I'd like to, but I there are some more bugs to be fixed, and with some
of the team on the move to Rennes, releases are likely way slower than
desired for a little while longer. -Christian
0x48426C7E.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
Should be fixed in SVN 34268. -Christian
0x48426C7E.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
Dear Bertrand,
Yes, I think we can/could add a configure option --force-curl to
GNUnet help you Debianize. Bart/Matthias, if you can figure out how,
please help, if not, I'll do it eventually ;-).
Happy hacking!
-Christian
On 08/23/14 09:26, Bertrand Marc wrote:
Hi Christian,
I am
I would have used decentralized in English (instead of 'trust-based')
and that would then also be better in German:
sicheres, dezentrales Netz
secure, decentralized (P2P) Network
You may add 'framework for' or leave that out, that's a detail IMO.
My 2 cents
-Christian
On 04/16/2014 04:19 PM,
Hi!
Just FYI, this bug was fixed in 0.9.4.
-Christian
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
After some more discussion with Bertrand, I've committed a patch to SVN
HEAD (SVN 24295) which allows the user to control NSS library
installation. There are a few possibilities:
1) If configure is run by root or using the '--with-sudo' option, NSS
plugins are by default installed to /lib
On 10/10/2012 09:30 PM, Bertrand Marc wrote:
Dear Christian,
Thank you for checking all these Debian bugs, it is really appreciated.
Yes my patch would place the NSS library in /usr/lib, I thought it was
ok. And my Debian scripting expect it in /usr/lib because that is where
it ends up on
Dear Bertrand,
After your patch, wouldn't the NSS library be no longer installed in
/lib and instead end up in the default /usr/lib location (which is
wrong)? The way I read the bugreport was that your Debian scripting was
wrong to expect it in /usr/lib/, so you should have fixed your packaging
That's right, gnunet-helper-exit (and a few other gnunet-helper
binaries) are not available on non-Linux systems (still need to be
ported). So in the meantime, the Debian packages should be updated to
not ship the subsystems of GNUnet that cannot work on FreeBSD (anything
to do with
Hi!
I believe this is most likely related to a problem with the UDP plugin
we discovered recently. Try disabling the 'UDP' transport in your
configuration, this might help. (Basically, retransmissions due to lost
packets on UDP were not properly accounted for, we're working on a patch).
Happy
The current version of GNU libextractor (1.0!) no longer uses
libpoppler, so this problem will go away when updating anyway.
Just FYI.
-Christian
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Patch looks fine, fixed as suggested in UPSTREAM Subversion 24008.
Thanks for the suggestion / fix.
-Christian
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
$ svn commit -m releaxing libgcrypt version check, fixing Debian #684997
Sendinggnunet/configure.ac
Sendinggnunet/src/util/crypto_random.c
Transmitting file data ..
Committed revision 24024.
Diff is pretty much in line with Werner's suggestions, except minimum
version is 1.4.2 (as
On 09/22/2012 12:05 PM, Bertrand Marc wrote:
(CCing upstream to try and solve the issue)
Hello Christopher, Hello Christian,
Le 26/08/2012 21:52, Christopher Schramm a écrit :
Starting GNUnet: libgcrypt has not the expected version (version 1.5.0
is required).
Ok, I understand the
Just FYI, upstream SVN 23854 fixes this by editing
src/datastore/datastore.conf.in (resulting in an equivalent change, just
to the default configuration in
$PREFIX/share/gnunet/config.d/datastore.conf).
-Christian
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a
Hi!
This is upstream. The suggestion is fine and has been applied in SVN
23742 in the development version (will be part of 0.9.4).
DDs: patching as suggested should be absolutely harmless.
Thanks for reporting!
Christian
--
To UNSUBSCRIBE, email to
That's because development has moved on in GNUnet and I think you're
using SVN HEAD. The tests were moved to the 'src/pt/' directory...
Best regards,
Christian
On 07/29/2012 02:51 PM, Jurij Smakov wrote:
tags 670578 unreproducible
thanks
Hi,
I finally got some time to look into this. I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
As the upstream maintainer, I recommend removal of gnunet-qt. -Christian
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I get this:
# gdb --args gnunet-service-mesh -c test_gnunet_vpn.conf
GNU gdb (GDB) 7.0.1-debian
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html
This is free software: you
Package: gcc-4.6
Version: 4.6.3-1
Justification: causes non-serious data loss
Severity: grave
When compiling GNUnet on our sparc buildbot, gcc decides to place
the hc variable from file
https://gnunet.org/doxygen/d7/dc5/gnunet-service-mesh_8c_source.html
in line 3860 at an inadequate stack
Package: libmicrohttpd
Severity: important
For reasons unknown to me, libmicrohttpd is still on an ancient
version with limited HTTPS support in Debian stable/testing/unstable.
A reasonably up-to-date version is only in experimental.
The current 0.9.x-series is stable, well-tested and widely
Package: libextractor
Severity: important
For reasons unknown to me, libextractor is still on an ancient
version prior to out-of-process execution and with the older
API in Debian stable/testing/unstable. Most applications that
I'm aware of have been modified to use the new API, so they can
On 02/15/2012 10:18 PM, Daniel Baumann wrote:
severity 660012 wishlist
tag 660012 pending
thanks
Hi Christian,
I'm uploading 0.9.19 to experimental as we speak, however, it cannot yet
go to unstable. It has to wait until the whole gnunet 0.9 stack will go
together to unstable.
Why? GNUnet
Package: libtasn1-3-dev
Version: 2.9-3
Severity: grave
Tags: sid
Justification: renders package unusable
I first got this error compiling some code:
/bin/sed: can't read /usr/lib/libtasn1.la: No such file or directory
libtool: link: `/usr/lib/libtasn1.la' is not a valid libtool archive
The file
more into this,
the problem seems to always arise when I link against libcurl. I have
libcurl3, libcurl3-gnutls and libcurl4-gnutls-dev installed (7.21.6-1).
I hope this helps!
Best,
Christian
On Tuesday, May 03, 2011 04:42:40 PM Simon Josefsson wrote:
Christian Grothoff groth
On Tuesday, May 03, 2011 07:02:17 PM Andreas Metzler wrote:
It was dropped from the Debian package recently when the last package
in Debian that required it (by refereing to it in depency_libs of its
own libtool la file) was fixed.
Ah, that recently explains it. I've tracked the issue down
Hi Daniel,
There is an important patch for Fossology and other LE users that fixes a bug
in 0.5.23. I've fixed it upstream (0.6-tree), but I think it warrants an
0.5.23-{X+1} Debian package (since it fixes http://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=531864). You can find the patch with
On Thursday 25 February 2010 06:19:26 pm Matt Taggart wrote:
Well, I don't see why they do the rpath thingy. -lextractor should be
all that is needed. Now, if fossology internally messes with libltdl's
lt_dlsetsearchpath and somehow removes the entries added by libextractor.
That *would*
Package: dh-make-drupal
Version: 0.4-2
Severity: grave
Justification: renders package unusable
When I run dh-make-drupal on any of about a dozen modules, I get the
error message from the subject above. In fact, I'm currently not aware
of a module that still works.
The script used to work just
On Thursday 10 December 2009 02:25:24 am Matt Taggart wrote:
Hi Christian,
Thanks for your mail to Debian bug #555982 regarding libextractor plugins.
I brought up the issue on that bug due to the policy concerns, but the
actual bug I am seeing is in the fossology package which uses
Hi!
LE upstream here. Have you considered setting LIBEXTRACTOR_PREFIX=/usr?
This should do the trick (LE will then look in /usr/lib/libextractor for its
plugins). If this variable is not set, LE will also try a heuristic, using
the path of the running binary and thus go from
FYI: This bug will be fixed upstream in the next GNUnet release. -Christian
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
We've filled this under https://gnunet.org/mantis/view.php?id=1299 and will
try to address this for the next release. -Christian
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
The issue is that it may not work with all NAT boxes -- the UPnP Microsoft
design is quite crappy and implementations differ slightly, and of course we
cannot simply test against all NAT boxes out there. You can go into the
src/transports/upnp/ directory and run make check to see if UPnP works
This is actually an issue in libgsf, not libextractor. I've reported this bug
to [EMAIL PROTECTED], the libgsf maintainer. Daniel, you may also want to
inform / check with [EMAIL PROTECTED], the Debian libgsf maintainer.
Christian
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a
First, I'm the GNUnet maintainer (upstream, not Debian).
I think this is the same bug as what was reported at:
https://gnunet.org/mantis/view.php?id=1278
The main problem is that I'm unable to reproduce the problem on my systems
(and I'm running Debian unstable). I've tried with guile-1.8
I just received a patch from Volker Weiss fixing the problem, including a
detailed description of why it was happening. The bug will be fixed in
doodle 0.6.6 (out shortly). -Christian (doodle author)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
In subversion revision #2496.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Package: kernel-image-2.6.8-11-amd64-k8
Version: 2.6.8-14
Severity: minor
After reconfiguration of permissions on a mounted SMB volume, the Kernel
decided to segfault (system continued to run, blocking processes that
were accessing the affected volume).
Here is what /var/log/messages had to
Package: libextractor
Severity: normal
The new version ships with many improvements and new plugins.
It should also fix #282342 and #295459 and has an extended API
that some 3rd party software requires.
-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux
Well, the assertion failure is clearly inherited from libgsf into libextractor
and should obviously be fixed. It's not clear to me if it relates to the
second problem that you mention: the incomplete database. For that I would
need more information -- for starters, are you sure that the
On Monday 04 April 2005 15:31, Arnaud Kyheng wrote:
severity 301822 wishlist
thanks
Hi all,
Daniel Baumann wrote:
I second that, otherwise it should be, for consistency, /var/lib/GNUnetd
etc. too.
M that's right.
I can't find anything in the Debian policy related to the logfile
Please run
$ ldd `which gnunet-gtk`
I suspect you're linking against an old version of the gnunet-util library on
your system (this should tell us). For example, I get this (having some
0.7.x prototype code installed locally):
[EMAIL PROTECTED]:~$ gnunet-gtk
gnunet-gtk: relocation error:
54 matches
Mail list logo
