>From https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962320 I guess
swapping libboost library versions may be a more proper fix. Though I
haven't tried this myself yet.
Huh https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962320 may in fact be a
duplicate.
On Fri, 12 Jun 2020, at 09:38, intrigeri wrote:
> > Some stracing uncovered that it was trying to read the following
> > directories:
> >
> > /opt/puppetlabs/facter/facts.d
> > /etc/facter/facts.d
> > /etc/puppetlabs/facter/facts.d
> >
> > through trial and Aborted errors I've created those and
Package: puppet
Version: 5.5.19-1
Severity: grave
Justification: renders package unusable
Since the recent Ruby upgrade, Puppet invocations have been very noisy for a
while already.
But by now it's not even starting. Even after a dpkg -P including most
dependencies (including apt-get remove
OK, there's always http://code.bitlbee.org/debian/README.html
Sorry for those who now end up without a BitlBee package. But really the
nightly builds are pretty stable. :-)
Patches are welcome while I don't have time for this.
Cheers,
Wilmer.
signature.asc
Description: OpenPGP digital
Yeah, this has always been a little bit iffy. Thankfully the
Skype-related packages can go away altogether. I'm not tracking BitlBee
development anymore but would expect that they go away in 3.6 (I'll have
to do the upload for it within the next few days so I'll verify).
signature.asc
Severity: 883872 minor
stop
Please quote the part of
https://www.debian.org/doc/debian-policy/#copyright-information that
says "every single file must be mentioned in the copyright file". I
don't see it there nor would I see the point as per-file info is best
off stored in those very files.
Let
severity 883872 minor
Machine-readable is optional, and although not all attributed by exact
file or directory, everything in the existing file *is* accounted for
(Lintux == me at, hmm, 16 years old, and various files also in lib/
still come from Gaim which is mentioned.)
Patches for a fully
Yeah already preparing a fix. Turns out the fix from 3.4-1.1 was a
different fix from the one posted by the NMU'er on the bug. :-(
This should fix itself when libotr5 4.1 enters testing. I'm told that
irssi-otr and pidgin have exactly the same issue.
--
+ .''`. - -- ---+ +- -- --- - --+
| wilmer : :' : gaast.net | | OSS Programmer www.bitlbee.org |
| lintux `. `~' debian.org | |
intrigeri (intrig...@debian.org) wrote:
If nothing has happened on this front, I'm afraid the OTR support in
BitlBee should now be considered as not maintained.
There's a fix actually, I've just not managed to take a closer look at
it, plus ther was some comment that it might not be complete
On 06-07-13 16:35, Adam D. Barratt wrote:
On Tue, 2013-06-04 at 14:47 +0200, julien.cris...@logilab.fr wrote:
your package build-depends on libotr2-dev, which is no longer built
in sid as it has been replaced by libotr5-dev. Please port your
package to the new library.
Any news?
The guy
Just had a response from him on Twitter now, might get a fix over the
next weeks.
Wilmer v/d Gaast.
--
+ .''`. - -- ---+ +- -- --- - --+
| wilmer : :' : gaast.net | | OSS Programmer www.bitlbee.org |
| lintux `. `~' debian.org | | Full-time geek
Nice catch, thank you! NMU sounds good, I'll merge this into my tree too
then.
Wilmer van der Gaast.
--
+ .''`. - -- ---+ +- -- --- - --+
| wilmer : :' : gaast.net | | OSS Programmer www.bitlbee.org |
| lintux `. `~' debian.org | | Full-time geek
with an insatisfiable
dependency. My buildbot sets a version number at runtime and annoyingly
that only sets binary:Version, not source:Version.
I'll unmerge this stuff. Please in the future don't just assume the
other guy must be an idiot, crazy hacks may have a purpose.
Wilmer van der Gaast
Ah yes, IIRC this is fixed in bzr already. I'll hopefully have a 3.0.1
ready soon. Since 3.x won't make it into testing anyway for now I won't
hurry.
Wilmer.
--
+ .''`. - -- ---+ +- -- --- - --+
| wilmer : :' : gaast.net | | OSS Programmer www.bitlbee.org
Package: bitlbee
Version: 1.2.5-1
Severity: serious
I should do an NMU of a new bitlbee-skype release before this package makes
it into testing. Opening this bug as a reminder and to hopefully keep it
out of testing.
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT
apt-get install rep
See also: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=556403
This was broken for me too, took me a while to find out what it was.
Eventually using GNOME instead became too painful and counter-productive
so I straced the thing and found the fix. :-)
Wilmer.
--
peter green wrote:
It looks like you forgot to really Cc them BTW?
I did but I resent the mail seperately to them afterwards.
Ah, found it. Looks like I'm not CC'ed on that anymore though. I think
it used to not work otherwise seems like a very good reason for me to
use the static lib. :-)
peter green wrote:
Does anyone know if there is any particular reason that bitlbee uses
libresolv.a rather than libresolv.so ?
Yes; the fact that Ulrich Drepper thought it'd be a good idea to declare
this API private and unsupported, claiming it's for internal use only,
even though it's
Alok G. Singh wrote:
Rebuilding the package on a buildhost with the latest libc6 (2.10.1-1)
installed creates a package that does not conflict libc6. No changes are
required except the rebuild.
So that's what confuses me. Are you seeing this problem on amd64 or some
different arch? Because
Alok G Singh wrote:
The libc6 version available in sid is 2.10.1-1, but bitlbee demands a version
strictly less than 2.10.
Note that I did not add that dependency myself. I have absolutely no
idea where it comes from and why it's not affecting any other package.
If you or anyone else who reads
}.)
or something similar.
@Frank: Sorry, I clicked on that link, but failed to notice the comment
on the page, only saw the list of broken packages. :-/ But yes, that
page explains the same thing and says that something similar is .1~. :-)
Thanks for your help,
Wilmer van der Gaast
forcemerge 530345 531219
thanks
Hello,
Philipp Kern wrote:
ASAP. (And by the way there are currently two other RC bugs open, both
uncommented since three months.)
Best of all, the one you're reporting is a dupe. :-)
But yeah, I should pay more attention to this; working on that now.
Looking at this now.
Depends: bitlbee (= ${binary:Version})
The dependency seems right already, it's a binary dep, not a source dep.
I see other programs just make the dependency less tight by doing
something like
Depends: foo (= ${source:Version})
Is that the best I can get? :-/
Wilmer.
Hmm. Yeah, that code *should* be temporary and was only aimed at
upgrades in sid.
Just to be on the safe side I'll see about adding a warning to
init/maintainer scripts. It can still go wrong when upgrading from 1.0.x
to 1.2.3 if the user doesn't pay attention to the diffs.
Wilmer.
--
Package: bitlbee
Version: 1.2.2-1
Severity: grave
Justification: causes non-serious data loss
There's another bug where a new user can overwrite existing accounts. This
does not give one access to anything that shouldn't be accessible, but it
does allow people to delete other people's accounts.
, hoping that the
problem will go away.
Wilmer van der Gaast.
--
+ .''`. - -- ---+ +- -- --- - --+
| wilmer : :' : gaast.net | | OSS Programmer www.bitlbee.org |
| lintux `. `~' debian.org | | Full-time geek wilmer.gaast.net
Package: bitlbee
Version: 1.2.1-1
Severity: grave
Tags: security
Justification: user security hole
Since the fix to Mickey Mouse bug report 474589, BitlBee is runing as root
for most people, since the User = line is commented out by default.
-- System Information:
Debian Release: lenny/sid
APT
severity 474589 minor
tags 474589 +pending
thanks
Marc Dequ?nes (Duck) ([EMAIL PROTECTED]) wrote:
Software is unusuable in ForkDaemon mode because you force running as
'bitlbee' user in the init script. Raised severity, as this is the
recommanded way of running bitlbee.
So, how does
out. :-)
Wilmer van der Gaast.
--
+ .''`. - -- ---+ +- -- --- - --+
| wilmer : :' : gaast.net | | OSS Programmer www.bitlbee.org |
| lintux `. `~' debian.org | | Full-time geek wilmer.gaast.net
.
If this isn't really a policy violation, I'd rather reduce the bug
severity a bit and fix this in 1.1 packages.
Wilmer van der Gaast.
--
+ .''`. - -- ---+ +- -- --- - --+
| wilmer : :' : gaast.net | | OSS Programmer www.bitlbee.org |
| lintux
The current BitlBee development version has a new daemon-mode, one that
fork()s off a process for every client. This gets rid of the inetd
dependency and has some of the daemon advantages (even though it still
fills up the process list a bit more, but that's just something we can't
avoid for now,
on the channels you're in.
AFAIK it's because the linestack module doesn't flush any data.
Unfortunately there is no other suitable version I can upload. If one
appears, I'll upload it right away.
Wilmer van der Gaast.
--
+ .''`. - -- ---+ +- -- --- - --+
| lintux
is disable the
linestack module, it's the main problem. But without that module,
ctrlproxy isn't really useful... :-(
Wilmer van der Gaast.
35 matches
Mail list logo