I am unable to reproduce this bug. It's a timing thing (fails if
something is too fast), so might fail if the machine is too fast, or
if the accounting on CPU time is off due to other threads and cache
misses not being counted against the right thread, or something like
that. In any case, I've lowe
Thanks for the bug report & patch.
Have merged it in git repo on salsa.
But there are so many mods in-tree I will probably just move it to be
a regular commit.
Anyway, planning to upload as soon as I create a pkgconfig .pc support
file, since the /usr/bin/libmcrypt-config it comes with is pretty
c
Well, it would certainly be simple enough: the source code should
compile fine, and the debian/* scripts would need only the very most
minor tweaks.
I've uploaded a package with this fixed to unstable, 1:2.24-5, and
it's been autobuilt and pushed out. Seems to work okay, and can be
co-installed with apache2/sid.
Just uploaded 1:2.24-6 that adds Breaks: apach2-bin per your recent message.
Honestly, I'm not confident in my ability to properly b
uploaded
will do
Bastien,
Okay, got it. Thanks for letting me know.
I can cherry-pick that fossil commit, but you know the right magic for
a versioned apache2 breakage and how to deal with proposed-updates.
So I think it would make sense for you to do all of this in a
coordinated fashion?
If that's okay with you,
The libddccontrol library is, to my knowledge, only used by packages
generated by the same source package, namely ddccontrol and
gddccontrol. And time_t is only used internally, not exposed via the
library's ABI. Under these circumstances, I don't think transitioning
libddccontrol is, technically s
I pushed a quick update, it has a few test failures though.
close 1023565
thanks
dleyna is back, baby!
I've done a bit more packaging of dleyna, pushed to
https://salsa.debian.org/debian/dleyna.git branch debian/main, mainly
moving to the latest upstream 0.8.2. My plan is to adopt it by
uploading, which hopefully will result in mopidy-dleyna becoming
usable and then I'll be able to listen to DLNA mu
close 1034629
thanks
Wow, thanks everyone for tracking this down so quickly!
I'm going to close it, since it was due to non-debian packages.
Thanks for noting that.
Already filed for RM, see bugs.debian.org/1033450
Thanks for the bug report.
On a "testing" system, with webcamoid 9.0.0-5.
$ rm -r ~/.cache/Webcamoid
$ webcamoid
[2023-01-20 12:04:13.838, Webcamoid, 0x7f432a7577c0, (0)] warning:
QSocketNotifier: Can only be used with threads started with QThread
[2023-01-20 12:04:14.975, Webcamoid, 0x7f432a757
Yes.
I patched over the issue for now by just using the internal sqlite3
library, so I think it can wait until the next official release to
pick up the proper bug fix and go back to using the system sqlite3
library.
close 1009161 3.4.2-6
thanks
close 984423 8.8.0+dfsg-1
thanks
close 992438 1.3-4
thanks
The executable passed to help2man must be referred to as ./gmi not just gmi,
and make seems to strip off the ./, so it must be explicitly included.
This doesn't seem like an autoconf issue, as the problem crops up
post-configuration. Unless I'm missing something. And, I'm unable to
reproduce it, using autoconf 2.71. Could you check if the current
version still exhibits the problem?
This doesn't seem like an autoconf issue, as the problem crops up
post-configuration. Unless I'm missing something. And, I'm unable to
reproduce it. Could you check if the version I just uploaded still
exhibits the problem?
Thanks for the report & digging out the relevant patch.
I uploaded the upstream 2.1.15~rc1 version, which includes this patch
and addresses a couple other issues as well.
Thanks for the report. I've been looking at the issue already.
Adding a new arch requires a bit of work, because there's a circular
build dependency so you have to build manually. And I don't have an
arm64 to hand, so I'll have to use a porter machine. Will get around
to it.
I doubt the i386 "out
close 957317 0.11pre0+cvs.2003.11.02-11
thanks
Patch from Alexey Sokolov fixed GCC-10 bug. Much appreciated!
Thank you! I'll merge your fix and do a non-NMU when I get a chance.
For future ref, no need to delay or even NMU. I don't mind my packages
getting a little TLC.
The latest upload fails test on more architectures, making me suspect
that fancy new compiler tech may be involved. Chained floating point
operations keeping guard digits inappropriately or something like
that, perhaps.
In all bad cases, test0 passes, and both test1 and test2 fail, both with:
cli
This is a really strange error. Nothing relevant has changed in the
package proper.
At first I thought it might be a race condition on the three tests,
but I can't find any.
My suspicion at this point is that it's an error in the floating point
support on the ARM64 platform. On the one hand, that
close 867505 0.2.8-1
thanks
"Rules-Requires-Root?"
"No"
"You Worm. You Scum. You Lowly User. REJECTED!!! Upper Case Is
Reserved For Your Betters. Do You Think You Are My Equal?"
"no."
"What Was That? Did You Just Use Punctuation? Do You Deserve To Use
Punctuation?"
"nope"
"What!?!? You Need Discipline. A GNU Kind Of Disciplin
"Rules-Requires-Root?"
"No"
"You Worm. You Scum. You Lowly User. REJECTED!!! Upper Case Is
Reserved For Your Betters. Do You Think You Are My Equal?"
"no."
"What Was That? Did You Just Use Punctuation? Do You Deserve To Use
Punctuation?"
"no"
"That's Better. Now I'm Sending You For A Session With T
ack
There's a new upstream version available, and I cannot update the
github-backup package until libghc-github-dev (>= 0.23) is available.
So I hope to see the new version packaged.
Cheers,
--Barak.
How about switching to clang; would there be any objections to that?
If a mips porter could rip all the space save and --parallel=1 stuff
out of debian/rules and build with
fakeroot debian/rules CXX=clang++-9 CC=clang-9 build
and if it works I think just switching would make sense.
It sounds like djview-plugin should just be removed, since it supports
a now-dead plugin API.
Any objections?
Great. I was about to look at doing an ACE NMU, so that's good to hear.
Turns out there is a new upstream version of the ACE libraries. Not sure if
the ACE team is actually active or planning to upgrade. Might be a good
idea to give them a ping.
Cheers,
--Barak.
This would appear to be in an ACE library header file, rather than in
the iv-tools package proper. Unless I'm missing something, it seems
like this report should be moved from iv-tools to ace.
close 949732 3.2.2-3
thanks
merge Ubuntu patch which addresses the issue
close 812704 0.9.18-12
thanks
patched to use latexmk instead of rubber
Thanks, that was very kind of you. Much appreciated. I'm in the
process of preparing to upload.
But next time feel free to just NMU, 0 day, tell me after, I totally don't mind!
(This goes for any of my packages.)
Cheers,
--Barak.
It appears that xemacs support has bit-rotted away, while plain
emacs25 installs fine. So I'm inclined to just mark this as
conflicting with xemacs25 and mark this as a wishlist bug, in case
anyone wants to figure out and fix the problem.
Objections?
--Barak.
Thanks. But even with that patch I'm still getting a build error with
valac 0.42.0-1
src/notification.vala:37.17-37.29: error: Equality operation: `null'
and `bool' are incompatible
if (_read != null) {
^
gcc -DHAVE_CONFIG_H -I. -DGETTEXT_PACKAGE=\""nuntius
close 901749 3.0.0-1
thanks
This issue was caused by chrpath being invoked even when the binaries
were not being installed. The use of chrpath during the build was
removed in 3.0.0-1, so this should no longer be an issue.
Oops, thought it was fixed. Ah well.
Just uploaded fix.
> I'm happy to upload an NMU if you're busy.
In the future please feel free to just NMU, 0 day, I don't mind.
For historic reasons the packaging repo is on github; I should really
move it to salsa Debian, and just mirror on github, to make this sort
of thing easier.
--Barak.
This is a recurrence of https://bugs.debian.org/701300 which was
caused by libace being compiled with a different version of the
compiler than ivtools, and these two versions mangling a particular
symbol differently.
If libace (src:pkg-ace) could be tickled into a rebuild against the
latest sid to
Thanks for spotting this.
The fossil build system does scan for tclsh and jimsh and if it finds
one of them it does not use its private copy of jimsh0.c.
So this shouldn't be a problem to fix.
(Well, except that it's hard to get uscan to do it automatically
because reasons.)
This bit me today too. In a lecture hall full of students.
Luckily I had SWI Prolog installed as well, or it would have been a serious
disaster.
--Barak.
$ cat mortal.pl
man(aristotle).
mortal(X) :- man(X).% for all X
$ gprolog
GNU Prolog 1.4.5 (64 bits)
Compiled Feb 5 2017, 10:30:08
close 870075
thanks
This was a legal @debian.org address, the issue was inappropriate blacklisting
of the domain by spam fighting services used by an involved ISP. Nothing to do
with this package per-se.
close 860657 2017.00.00.4-1
thanks
test failure, apparently fixed upstream
I'm always happy to have someone else upload a fix, just go ahead and do it.
But in this case, the latest upstream no longer manifests the problem.
Since there was no fix to the div.cpp test case, I suspect it was an
actual bug that the test case picked up and upstream fixed. But I have
not bothere
Well, vicare is a sort-of fork/continuation of ikarus.
If that compiles on i386, we could transition.
Or, since this problem is i386-only, and I'd imagine most users are
amd64, could just stop supporting i386.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Parallel builds were failing for some other mysterious reason, so I
was trying to get that worked out. But in the interests of sanity I
simply disabled parallel builds and uploaded the fixed version. Thanks
for the nudge!
Cheers,
- --Barak.
-BE
There is upstream activity, at http://xgraph.org, which I'm looking into.
If nothing happens I think the package can go, but please queue this
up another few weeks...
Cheers,
--Barak.
Thanks for the report.
Just pushed a fix.
(This issue was not upstream, just in the debian packaging goo.)
> Barak, can you do the necessary upload? You seem to be most involved
> with the package these days, so feel free to "promote" yourself to
> maintainer.
Will do.
> http://pkg-emacsen.alioth.debian.org/
https://. And even better: I'll do that!
Two other minor matters.
(a) For this or any of m
Thanks that's fantastic, i appreciate your looking into it. I'll get this
uploaded as soon as NIPS is over and its chemical aftereffects have cleared
my system.
close 818814 2.0.2
thanks
fixed upstream
Good catch.
When i get a chance I'll just upload with myself as maintained and close
this.
So maybe the best thing would be to file a bug against qt5, fix things
in this package by using qt4, and filing a wishlist bug against this
package to use qt5, with a "blocked by" referring to the qt5 bug
report above. That way when the qt5 issue is resolved the wishlist bug
will be unblocked and n
Is there any reliable way to test for the buggy version of Qt-5?
Because if there is we could do something in debian/rules or some
place like that to fall back to Qt-4.8 iff Qt-5 is unavailable or
buggy.
> There's really no reasonable way to support versions of emacs older than
> 24 with the elpa based infrastructure. Indeed most emacs addon packages
> just won't work, never mind packaging issues. I guess a versioned depend
> on emacs would do the trick to pull in emacs24. If that seems like the
>
let's go ahead and kill it
.
So I'd rather figure out the actual problem and address it, rather
than simply masking this particular manifestation.
Any assistance in this regard would be quite welcome.
--
Barak A. Pearlmutter
Dept Comp Sci & Hamilton Institute, Maynooth University, Co. Kildare, Irel
> Thanks for the prompt reaction.
My pleasure.
> ettercap is also in Squeeze and thus covered by our LTS initiative.
> Do you feel like providing a fixed package for Squeeze?
> If yes, please have a look at http://wiki.debian.org/LTS/Development
> but note that if you provide the fixed package
not mean I
consider fixing it any less important.
--Barak.
--
Barak A. Pearlmutter
Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland
http://www.bcl.hamilton.ie/~barak/
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debi
--Barak.
--
Barak A. Pearlmutter
Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland
http://www.bcl.hamilton.ie/~barak/
signature.asc
Description: PGP signature
Thanks, that sounds like exactly the right debian/control dependency
magic. Will do, and upload.
> BTW, why are ettercap-graphical and ettercap-textonly not
> co-installable? Sounds like a candidate for renaming the binaries
> from ettercap to ettercap-foo and using alternatives to provide the
>
--Barak.
(ivtools maintainer)
--
Barak A. Pearlmutter
Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland
http://www.bcl.hamilton.ie/~barak/
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "u
.
--Barak.
--
Barak A. Pearlmutter
Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland
http://www.bcl.hamilton.ie/~barak/
pgpJfMzWVtZWT.pgp
Description: PGP signature
should some
of them be merged? Naturally things that make this easier to package
for Debian would probably also make it easier in other systems, like
Redhat.
Thoughts?
--Barak.
--
Barak A. Pearlmutter
Hamilton Institute & Dept Comp Sci, NUI Maynoo
/usr/include/qhull/liqhull.h. So building with liqhull-dev (>=
2012.1-3) might solve this problem.
But in the longer term, it would be best to transition to the new path
and filename.
Cheers,
--Barak.
--
Barak A. Pearlmutter
Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Kildare, I
> Any progress here?
> Today it's one year since I sent my first message.
Naturally this got buried.
Thanks for the reminder.
(xgraph does so little, it is tempting to drop it and just replicate its
functionality in something more modern and extensible.)
C
this issue was fixed in an upload that was done before your report came in.
(but: thanks for the report & correct diagnosis & appropriate fix!)
--Barak.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.
heers,
--Barak.
--
Barak A. Pearlmutter
Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland
http://www.bcl.hamilton.ie/~barak/
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Troub
: it hold
a representation of the architecture the binary being installed was
built for.
--Barak.
--
Barak A. Pearlmutter
Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland
http://www.bcl.hamilton.ie/~barak/
--
To UNSUBSCRIBE, emai
This issue appears to be due to a change in the way the linker treats
weak symbols, and a bug thereof. See http://bugs.debian.org/710936
which states that the problem has been noted upstream and a fix is on
the way.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subj
ugh.
Will upload the active fork, vicare, one of these days...
--Barak.
--
Barak A. Pearlmutter
Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland
http://www.bcl.hamilton.ie/~barak/
--
To UNSUBSCRIBE, email to debi
Thanks for catching the issue.
I closed it because, although this was not something you could have
known, the issue was resolved a very long time ago, as stated in the
message accompanying the close command:
relicenced GPL-3 by upstream prior to 0.0.2, see
https://groups.google.com/group/ikaru
close 708954 0.0.2-1
thanks
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
No that's great, thanks!
--Barak.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
g this out.
--Barak.
--
Barak A. Pearlmutter
Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland
http://www.bcl.hamilton.ie/~barak/
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> will file the t-p-u request. When the approval from the release team is
> granted, I will ask for sponsorship to do the upload.
thanks.
(naturally I'm happy to sponsor.)
--Barak.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with
7;t mind. Hint Hint.
--Barak.
--
Barak A. Pearlmutter
Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland
http://www.bcl.hamilton.ie/~barak/
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscri
> dpkg intentionally does not replace directories with symlinks and
> vice versa.
Okay, I'll add postinst stanzas.
But do you know *why* dpkg has this behaviour? Just curious, as it
seems on the face of it somewhat odd.
--Barak.
--
To UNSUBSCRIBE, emai
I think (but am not certain) that this is actually a dpkg bug.
The /usr/share/doc/ettercap-text-only directory in the old version has
become a symbolic link to /usr/share/doc/ettercap-common in the new
version. This is explicitly allowed in Policy 12.5,
/usr/share/doc/package may be a symbolic
y improves security, and certainly makes the package more
auditable. But, they do not really change the generated binaries
(except for moving library files to multiarch dirs.)
--Barak.
--
Barak A. Pearlmutter
http://www.bcl.hamilton.ie/~barak/
--
To U
> The cson_amalgamation.c file is only used by Fossil is you build
> with "configure --json". So, omit the --json on Debian (which you
> are probably already doing anyhow.)
Right, the only config option used now is --disable-internal-sqlite.
But unfortunately this is not quite enough to satisfy t
package must run as root, and
by nature tends to process potentially-hostile network flows, these
are somewhat serious.
--Barak.
--
Barak A. Pearlmutter
Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland
http://www.bcl.hamilton.ie/~b
Yeah you're right, common-lisp-controller would be the thing.
Patches welcome!
--Barak.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Yeah. The "right thing" is to either:
- disable the functionality
- have a per-user exported fasl file dir in their home directory, and
an easy way for users to add other users they trust to their search
path
- have a setuid program that builds fasl files from trusted sources,
which
It should be straightforward to fix by removing the undesired
flags from the short script icu-config, perhaps using a short
sed script.
--Barak.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble?
for building libraries, not
just linking against them.
Should this bug be filed against libicu-dev instead?
--Barak.
--
Barak A. Pearlmutter
Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland
http://www.bcl.hamilton.ie/~b
I am happy to sponsor this upload; will dput the built package in a
moment.
Two tangential points.
First, examination of the source reveals that the packaging is quite
old, and could use some updating.
Second, upstream development has restarted in a git repo on
sourceforge.
I would imagine that the FTP Team's decision on that was for actual
source code: computer instructions which are *run* at some point.
You know, a waf file which is *used*.
Since that is not the case for this particular file, it may well be
just fine with them.
Perhaps an FTP Team member could com
> I mean you need to repack it "like" what we do with those package
> needs to be DFSG free.
Sure, but why bother? The material itself is both DFSG free and
unused. It is not executed, so there is no need to make sure tools
can grok it or its format.
--Ba
> By either of the two solutions, you need to repack the upstream
> source to remove the problematic files, just like what we did with
> other packages to make their source tarball DFSG free.
This waf issue has nothing to do with being DFSG free.
It is a policy question concerning making examining
cally transforming an unused file from one format to another;
is that really a sensible freedom-enhancing act?
--Barak.
--
Barak A. Pearlmutter
Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland
http://www.bcl.hamilton.ie/~barak/
--
To UN
> I don't think it's so hard. Could you look over the proposed changes
> at
>
> git://git.debian.org/~jrnieder-guest/adolc.git
Yup: that looks about right.
I'll figure out and perform the right magic (an incantation in
debian/changelog I suspect) to cause it to wend its way into the
stable upd
> AFAIK, that does require that the files be removed from the source package.
They are already removed from the latest source package.
The question is if we want to go through the bother of removing them
from *old* source packages, which would be a lot of work, for dubious
benefit. I certainly h
Patch available,
https://github.com/barak/liboping/commit/e218b9a3a282570eed2853fc383a9d816bce29d0
--Barak.
--
Barak A. Pearlmutter
Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland
http://www.bcl.hamilton.ie/~barak/
&
1 - 100 of 166 matches
Mail list logo
