On Fri, May 31, 2024 at 10:56:54AM +0200, Thomas Viehmann wrote:
> This is fixed upstream in Jupyter Notebook 6.5.6 per
> https://github.com/jupyter/notebook/issues/7054
Will someone from the python team will fix this or should
I prepare a minimal NMU with the patch applied ?
Cheers,
--
EFINE'=> '-DOPENLDAP',
+ 'DEFINE'=> '-DOPENLDAP -DLDAP_DEPRECATED=1',
)),
'depend'=> { 'LDAPapi.c' => 'constant.h' },
'clean' => { 'FILES' => 'constant.h' },
The patch is from Quanah Gibson-Mount . Thanks.
Bill
This is a confirmed bug. I am working on a solution.
Bill
eared binary NEW.
Have you actually checked that pari will really be build with the relevant
flags ?
If there is a new ABI, then one should take the opportunity to remove
CFLAGS_i386 := -mpc64
There is no need for a lintian override, this is a well-known lintian bug...
Cheers,
Bill
ks out.
Fortunately libgap.so.9 was prereleased today.
Would that mess anything if I upload it to experimental ? I expect not.
Cheers,
--
Bill.
Imagine a large red swirl here.
On Thu, Feb 01, 2024 at 04:30:40PM +0100, Lukas Märdian wrote:
> Am 01.02.24 um 16:13 schrieb Bill Allombert:
> > On Thu, Feb 01, 2024 at 04:07:38PM +0100, Lukas Märdian wrote:
> > > Hi Bill,
> > >
> > > thanks for the heads-up!
> > > The same de
On Thu, Feb 01, 2024 at 04:07:38PM +0100, Lukas Märdian wrote:
> Hi Bill,
>
> thanks for the heads-up!
> The same debdiff should apply to the version in unstable (4.12.1).
> We'll make sure to NMU the version from unstable.
How do you plan to make sure libgap8t64 actual
rsion instead of
introducing libgap8t64.
So if one really need to introduce libgap8t64, we need a patch for the version
of GAP in unstable that actually use 64-bit time_t.
Cheers,
--
Bill.
Imagine a large red swirl here.
x27;
Downgrading nlohmann-json3-dev to 3.11.2-2 fixes this issue.
binNMUing libxeus9 might fix this issue, but will probably silently change the
ABI of libxeus9 without
updating the shlibs. This is worrysome. I hope I am wrong about that.
Cheers,
--
Bill.
Imagine a large red swirl here.
later fail. Which meant that my bisection attempts
where pretty much useless. I will work on a better test for this issue.
Bill
--
"Can't sing louder than the guns when I'm gone,
so I guess I'll have to do it while I'm here."
Phil Ochs
s, could you please intervene? Thank you.
This is premature.
> In the meanwhile, I'll immediately revert the sabotage.
If this package is so important, why is it maintained by NMUs ?
Why cannot the maintainers do a proper upload ?
Cheers,
--
Bill.
Imagine a large red swirl here.
pilgrim:/etc/fapolicyd/rules.d# ls
90-deny-execute.rules
pilgrim:/etc/fapolicyd/rules.d# cat 90-deny-execute.rules
# Deny execution for anything untrusted
deny_audit perm=execute all : all
pilgrim:/etc/fapolicyd# cat fapolicyd.conf
#
# This file controls the configuration of the file access poli
actually ran on i386 binaries anymore ?
lintian.debian.org only lists reports for amd64 packages.
I am not sure it is worth the trouble, frankly. I do not see what this would
bring us.
Cheers,
--
Bill.
Imagine a large red swirl here.
9/copyright
>
> This issue may related to changes in the build system. While libjpeg.so.9*
> appear in the old version 1:9d-1, a rebuilt package of version 1:9d-1 on a
> latest unstable Debian system also lacks libjpeg.so.9*.
Ah thanks. I should have checked that the NMU was correct.
Cheers,
--
Bill.
Imagine a large red swirl here.
me if I
> should delay it longer.
It is a bit pointless, but if that suites you...
Did you manage to test the package ?
Cheers,
--
Bill.
Imagine a large red swirl here.
On Fri, Oct 28, 2022 at 07:26:09PM +, Tobias Hansen wrote:
> Thanks! I will apply the patch once the pari version with the other fixes is
> uploaded.
Great! I uploaded it today (pari 2.15.1~pre1-1). I hope it will be OK.
Cheers,
--
Bill.
Imagine a large red swirl here.
On Wed, Oct 05, 2022 at 10:41:58PM +0200, Bill Allombert wrote:
> On Wed, Sep 21, 2022 at 11:57:40PM +0300, Adrian Bunk wrote:
> > Testing cypari2.gen
> > **
> > File
> > "/<>/.pybui
hread stack overflows !
> current stack size: 1024000 (0.977 Mbytes)
> [hint] set 'threadsizemax' to a nonzero value in your GPRC
Probably you just need to increase threadsize or parisize, 1024000 is very
small.
Cheers,
--
Bill.
Imagine a large red swirl here.
On Mon, Oct 17, 2022 at 08:44:52AM +, Tobias Hansen wrote:
> Control: block -1 by 1020436 1020456
>
> Before sagemath can be fixed, cypari2 and giac have to be built against pari
> 2.15.
OK, is there someone taking care of giac ?
Cheers,
--
Bill.
Imagine a large red swirl here.
Once we get to the point it is the only remaining show stopper, I will
update PARI/GP in sid.
Cheers,
--
Bill.
Imagine a large red swirl here.
tual):
> - [1416875, [2, -1; 5, 4; 2267, 1], x^6 - 240*x^4 - 2550*x^3 - 11400*x^2
> - 24100*x - 19855, [[2, [2, [Mod(1, 2)]], []], [5, [1, []], ["[V] page 156",
> [3]]], [2267, [2, [Mod(432, 2267)]], ["[I{1-0-0}] page 170", []
> ? ^^ -- ^^^ --- ^^
> ^^
> + [1416875, [2, -1; 5, 4; 2267, 1], [-6*x^5 + 2*x^3 - x, x^3 + 1], [[2,
> [2, [Mod(1, 2)]], []], [5, [1, []], ["[V] page 156", [3]]], [2267, [2,
> [Mod(432, 2267)]], ["[I{1-0-0}] page 170", []
> ? ^^^^^ ^^^ ^
This error and below come from the new code for genus2red that return a minimal
model as
a vector of two components instead as a single equation, which was not minimal
for p=2.
Cheers,
--
Bill.
Imagine a large red swirl here.
sue warning.
In PARI we changed EVAL_f to cast the pointer to the right prototype
before calling it.
Sorry for the trouble.
Cheers,
--
Bill.
Imagine a large red swirl here.
.0-2, please apply the attached patch.
Cheers,
--
Bill.
Imagine a large red swirl here.
Index: clisp-2.49.20210628.gitde01f0f/modules/pari/pari.lisp
===
--- clisp-2.49.20210628.gitde01f0f.orig/modules/pari/pari.lisp
+++ clisp-2.
PM Bill Deegan
> wrote:
> > SCons 4.0.1 is fairly old and doesn't seem to be compatible with Python
> 3.10.
> > The latest SCons 4.4.0 is available and works fine with Python 3.10
> Actually it's not a compatibility issue, but a behaviour change with
> Python 3.
SCons 4.0.1 is fairly old and doesn't seem to be compatible with Python
3.10.
The latest SCons 4.4.0 is available and works fine with Python 3.10
On Sat, Sep 17, 2022 at 11:45 PM Lucas Nussbaum wrote:
> Source: scons
> Version: 4.0.1+dfsg-2
> Severity: serious
> Justification: FTBFS
> Tags: book
I am the developer of redet. I don't understand this bug report. redet does
not use anything called dpatch so far as I know. Is this something added in
the Debianization of redet downstream from me?
On Fri, Feb 18, 2022 at 8:27 AM Moritz Muehlenhoff wrote:
> Source: redet
> Version: 8.26-1.4
> S
with return code 2
Hello Thorsten,
Is it not the same as #955393 ? gpg1 is not supported.
Cheers,
--
Bill.
Imagine a large red swirl here.
html .
> The severity of this bug will be changed to 'serious' after a month.
Hello Lucas,
I will need a bit more time because testing popcon is slow...
Cheers,
--
Bill.
Imagine a large red swirl here.
> The severity of this bug will be changed to 'serious' after a month.
Hello Lucas,
Would you mind give me one more month, we are working on a new upstream
version...
Cheers,
--
Bill.
Imagine a large red swirl here.
mktemp instead.
Thanks for reporting this bug and tell me about this removal!
Cheers,
--
Bill.
Imagine a large red swirl here.
ackages.
>
> printer-driver-pnm2ppa still requires it.
It will also break any local shell scripts the user systems might depend
on that happens to use tempfile, for little or no benefit to the users.
Cheers,
Bill.
On Sat, Mar 13, 2021 at 04:21:02PM +0100, Dennis Filder wrote:
> Good, I just tried it with linphone 4.4.21-2, linphone-desktop 4.2.5-3
> and soci 4.0.1-5 and chat message history restoration works nicely.
That's great to hear! Glad you got it sorted out.
l file the unblock request once that's done.
Since we're in the freeze, I'm going to hold off on applying the test
regen patch for now, but I'll add it eventually.
Best regards,
Bill
e would please file a bug
against SOCI regarding this, I would appreciate it.
Best regards,
Bill
--
GPG: 5CDD 0C9C F446 BC1B 2509 8791 1762 E022 7034 CF84
Package: freewheeling
Followup-For: Bug #946863
X-Debbugs-Cc: bill-au...@programmer.net
this RC bug has caused freewheeling to be dropped from [testing]
this week
i have uploaded a patched v0.6.4 to the mentors repo (0.6.4-1.1);
which includes the necessary changes for fluidsynth2 support,
back
Hi,
I've uploaded xalan 1.12 to unstable. If you would like me to NMU
xml-security-c with the necessary changes (attached to 977568), I would
be happy to do so.
Best regards,
Bill
--
GPG: 5CDD 0C9C F446 BC1B 2509 8791 1762 E022 7034 CF84
Hi,
Thanks for your report.
I hope to address these issues next week.
Best regards,
Bill
tbfs
> Usertags: ftbfs-20201119 ftbfs-bullseye
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
Thanks Lucas!
This is the same bug as #975216.
This is caused by the upgrade of pari to 2.13.0.
Cheers,
Bill
On Sat, Nov 07, 2020 at 02:32:41PM +0100, Julien Puydt wrote:
> Le samedi 07 novembre 2020 à 11:05 +0100, Bill Allombert a écrit :
>
> Too late for that, I'll close by hand.
Thanks!
> > > but still, crashing is pretty bad : it should detect
> > > the value is
On Sat, Nov 07, 2020 at 10:29:18AM +0100, Julien Puydt wrote:
> Le jeudi 05 novembre 2020 à 19:12 +0100, Bill Allombert a écrit :
> > On Mon, Nov 02, 2020 at 09:57:07AM +0100, Bill Allombert wrote:
> > > This means 512000 is not sufficient. This is a fatal error.
> >
On Mon, Nov 02, 2020 at 09:57:07AM +0100, Bill Allombert wrote:
> On Mon, Nov 02, 2020 at 08:54:02AM +0100, Julien Puydt wrote:
> > Package: libpari-dev
> > Version: 2.13.0-2
> > Severity: grave
> >
> > The last pari upload broke giac on amd64, arm64 and mipsel
n 32bit but not
on 64bit.
The segfault is incidental. It is probably caused by giac not recovering
properly from such fatal errors. Do you have a backtrace of the
segfault ?
Cheers,
Bill
> _outside_ the source root, but _to_ the source root.
> > This leads to a spurious FTBFS.
I lowered the severity to important because gap-atlasrep has been updated
to avoid this FTBFS and according to Lucas there are no other packages
affected in unstable.
Cheers,
--
Bill.
Imagine a large red swirl here.
On Mon, Sep 28, 2020 at 05:19:33AM +0200, Guillem Jover wrote:
> Hi!
>
> On Sun, 2020-09-27 at 22:53:13 +0200, Bill Allombert wrote:
> > On Sun, Sep 27, 2020 at 08:58:00PM +0200, Lucas Nussbaum wrote:
> > > During a rebuild of all packages in sid, your package failed
ommand 'dpkg-source --no-check -x gap-atlasrep_2.1.0-2.dsc'
failed.
There is no rationale to reject such a symlink which does not point
_outside_ the source root, but _to_ the source root.
This leads to a spurious FTBFS.
Also I am concerned that developers might need to unpack old packages
with symlinks in them. There should be a way to do it, if only to fix
the packaging.
Cheers,
Bill
a FTBFS.
This is a symlink that is never dereferenced, and /<> is
not outside of /<>.
There is nothing that prevents debian/rules to create and uses such a
symlink either.
Probably this should be reassigned to dpkg.
Cheers,
--
Bill.
Imagine a large red swirl here.
Ok
Can you check the 4.0.1 tarballs and see if they provide in each what you
need?
We completely reimplemented packaging in 4.0.0
On Thu, Jul 30, 2020 at 5:39 AM Ben Hutchings
wrote:
> On Wed, 2020-07-29 at 16:26 -0700, Bill Deegan wrote:
> > So what is this issue?
> > Which
So what is this issue?
Which tarball debian packages are using as their source?
On Wed, Jul 29, 2020 at 4:23 PM Ben Hutchings
wrote:
> On Wed, 2020-07-29 at 16:11 -0700, Bill Deegan wrote:
> > Note there's a bug for this on SCons tracker.
> > https://github.com/SCo
Note there's a bug for this on SCons tracker.
https://github.com/SCons/scons/issues/3759
Please add any comments there.
On Wed, Jul 29, 2020 at 4:06 PM Ben Hutchings
wrote:
> Source: scons
> Version: 3.1.2-2
> Severity: serious
>
> Dear Maintainer,
>
> The current source package uses the 'produ
current kernel ABI version is 7
In the file /usr/lib/gap/sysinfo.gap
GAParch=x86_64-pc-linux-gnu-default64-kv7
GAP_KERNEL_MAJOR_VERSION=7
kv7 mean kernel version 7.
If your package is built against the GAP 4.11.0 kernel, please make it
depends on gap-kernel-7.
Cheers,
--
Bill.
Imagine a large red
On Thu, Apr 30, 2020 at 10:35:49AM +0400, Jerome BENOIT wrote:
> Dear Bill, thanks for your message.
Hello Jerome
> I understand that GAP comes now with an official ABI.
Yes, one for gap-core which is gap-kernel-7,
and one for libgap which is libgap7, but they should be
compatible.
>
current kernel ABI version is 7
In the file /usr/lib/gap/sysinfo.gap
GAParch=x86_64-pc-linux-gnu-default64-kv7
GAP_KERNEL_MAJOR_VERSION=7
kv7 mean kernel version 7.
If your package is built against the GAP 4.11.0 kernel, please make it
depends on gap-kernel-7.
Cheers,
--
Bill.
Imagine a large red
kernel ABI version is 7
In the file /usr/lib/gap/sysinfo.gap
GAParch=x86_64-pc-linux-gnu-default64-kv7
GAP_KERNEL_MAJOR_VERSION=7
kv7 mean kernel version 7.
If your package is built against the GAP 4.11.0 kernel, please make it
depends on gap-kernel-7.
Cheers,
--
Bill.
Imagine a large red swirl
> If it works on gcc 8.3, does that mean it works with the version in stable as
> well? The current version in stable was built wit gcc 8.3.0-6.
Yes, the gcc 8.3 I use now is the version in stable.
Cheers,
--
Bill.
Imagine a large red swirl here.
On Sun, Apr 12, 2020 at 12:02:38PM +0200, Ivo De Decker wrote:
> Hi Stephen, Bill,
>
> While looking at RC bugs that have been open for I while, I noticed this one.
>
> On Thu, Mar 07, 2019 at 09:07:15AM +0100, Stephen Kitt wrote:
> > Subject: Re: Bug#923698: gcc-mingw
On Sat, Apr 04, 2020 at 04:42:57PM +0200, Tobias Hansen wrote:
> Source: gap-atlasrep
> Version: 2.1.0-1
> Severity: grave
>
> Hi Bill,
>
> during a test build of sage I noticed that the newly updated gap-atlasrep
> package seems to be seriously broken. Trying the
Hey Christian, et al,
Yeah, the sounds probably included a lot of samples from the real
Defender arcade game, probably taken from a sound archive FTP site,
back in the day.
The Bill Gates image was based on art from Slashdot; and yeah,
somehow, they gave me permission to use it.
I've
Source: gap-guava
Version: 3.14+ds-1
Severity: serious
Dear Debian Science Maintainers,
gap-guava 3.14+ds-1 is failing the autotest with gap 4.10.2.
Please rebuild the package for the new GAP version.
Cheers,
--
Bill.
Imagine a large red swirl here.
It appears that the needed changes are located in Salsa [1], and that the
release was prepared but not uploaded (since it's nowhere to be found).
This package is team maintained, and since it's not clear to me if the
rest of the team is aware of this issue, I'm CC'ing the team address in
this mess
ipt completly rather than enabling it without restriction.
Cheers,
--
Bill.
Imagine a large red swirl here.
Package: python3-django-casclient
Version: 1.2.0-2
Severity: grave
Tags: upstream patch
Due to middleware API changes in Django 1.10, django-cas-client 1.2 no
longer works (fails with an unhandled exception). This currently
effects stable, testing, and unstable (oldstable used django 1.7). So
un
On Thu, Mar 07, 2019 at 09:07:15AM +0100, Stephen Kitt wrote:
> Hi Bill,
>
> On Mon, 4 Mar 2019 00:39:00 +0100, Bill Allombert wrote:
> > Since the upgrade to 8.2.0-17, gcc-mingw-w64-x86-64 miscompiles PARI/GP.
> > <https://pari.math.u-bordeaux.fr>
> >
>
please do try to keep this package from being dropped
i am the upstream maintainer and i have been trying for about 18 months to
contact debian user piem about this package; and working with the MIA team for
over a year - the upstream repo is is good shape with up-to-date autotools,
with the cu
The fix for stable has been uploaded to proposed-updates, and should be
included in the next point release. Oldstable was not affected by this
bug, so nothing was needed there.
My apologies for this - this is my fault.
I'm about to upload the fix to unstable, and will submit an update for
for stable and oldstable to hopefully be included in the next point
release.
Bill
While this is fixed for unstable/testing, the security team has informed
me that there will be no DSA for this issue for stable/oldstable.
As such, I'm reopening this until stable/oldstable can be updated via a
point release.
Package: xen-system-amd64
Version: 4.8.1-1+deb9u1
Severity: critical
Justification: breaks the whole system
Dear Maintainer,
* What led up to the situation?
Initially an attempt was made to upgrade an existing Jessie
Xen 4.4 system to Stretch Xen 4.8. When that failed I decided
fident it
> won't regress in other cases is really short. :(
It would be really nice if we could remove the circular dependency
between openjdk-8 and ca-certificate before the release, otherwise
the stretch to buster upgrade will be a nightmare.
It always much easier to add circular dependency than to remove them.
Cheers,
Bill.
For what it is worth, according to
<http://debian.semistable.com/unstable_diffs.txt>
a circular dependency between ca-certificates-java and
openjdk-8-jre-headless has been added on Thu Jun 1 01:02:00 CEST 2017
Cheers,
--
Bill.
Imagine a large red swirl here.
My dwww was working fine until applying the latest updates.
If it was logged and I knew where to look, I would show you the exact date
/ time that dwww was updated.
This is an especially frustrating bug as I use the dwww facility all the
time. :(
Sincerely,
Bill
(Sent from my GMail account)
orry for the delay, for some reason my ISP blocked this email.
Do you know how much memory is there on this system ?
The test suite need 128M which does not seems unreasonable.
I did a test build using cowbuilder for stretch i386 and it worked fine.
It seems to me your system was experiencing a memory crunch during the
build.
Cheers,
Bill.
lower the severity, and still look for a cause/fix. This
seems better to me than closing the bug and opening a new one for follow
up.
Bill
On Fri, Dec 16, 2016 at 08:25:02AM +, Gianfranco Costamagna wrote:
> Hi,
>
>
> >export DEB_BUILD_MAINT_OPTIONS=noopt
>
> >
> >to the top of d/rules and rebuilding should do it.
>
>
> it worked:
> DEB_BUILD_OPTIONS=noopt dpkg-buildpackage
>
> [...]
>
Interesting. Under the emulator some
On a whim, I decided to install the Hercules s390 emulator and see if I
could reproduce the problem there. It's slow (4+ hours to do a build of
xerces) but it appears to work, and the issue shows up there as well.
I started trying to trace down the memory issue in real time, but the
variables I
On Wed, Dec 14, 2016 at 07:11:12AM +, Gianfranco Costamagna wrote:
>
> >So while I'm not sure it will help, there might be benefit to try to get a
> >stack trace from DOMCount. It's possible there's an exception being
> >thrown but it's getting caught/squashed. If someone wants to try to get
7;s an exception being
thrown but it's getting caught/squashed. If someone wants to try to get
a stack trace, the command will be
libtool --mode=execute gdb --args samples/DOMCount samples/data/personal.xml
and the steps inside of gdb will be the same as before.
In the mean time, I'll dig back into the source.
Thanks!
Bill
On Tue, Dec 13, 2016 at 12:06:46PM +, Gianfranco Costamagna wrote:
> Hi
>
>
> >Based on the stack trace, the exception is thrown because a managed
>
> >buffer that is being freed isn't actually registered to the buffer manager.
> >his shouldn't happen, since the only way to get a buffer is t
ttached patch comments out the line that throws the exception,
causing the function to simply return. This should let the program
continue running, hopefully producing useful output (whether correct or not).
Could someone please apply the patch and rebuild?
Thanks,
Bill
diff --git a/src/xerce
x27;t find the debug symbols for the other backtrace, but for yours
it did. This could help.
Thanks,
Bill
On Sun, Dec 11, 2016 at 07:43:08PM +0100, Mattia Rizzolo wrote:
> On Sun, Dec 11, 2016 at 01:34:18PM -0500, Bill Blough wrote:
> > I just found a reference in the Debian Maintainer's Guide that says the
> > default build locale is C. And it looks like the Ubuntu build is
>
On Sun, Dec 11, 2016 at 06:20:13PM +, Mattia Rizzolo wrote:
> anyhow, 1) build should not depend on the locale it runs
I'll admit, I don't know a lot about locales, etc., but some of the
tests use files in UTF-8. Wouldn't that generally require UTF-8 support
from the locale?
> 2) afaik it isn
On Sun, Dec 11, 2016 at 05:57:38PM +, Gianfranco Costamagna wrote:
> Hi,
>
> >Does anyone know (or can find out) the default locale on the s390
> >systems, and does that differ from the other architectures?
> >
> >env | egrep "(LC|LANG)"
> >
> >should give a list of relevant vars.
>
>
> (not
Does anyone know (or can find out) the default locale on the s390
systems, and does that differ from the other architectures?
env | egrep "(LC|LANG)"
should give a list of relevant vars.
Thanks,
Bill
On Sat, Dec 10, 2016 at 08:56:29AM +, Gianfranco Costamagna wrote:
>
> > libtool --mode=execute gdb --args samples/SAXCount
> > samples/data/personal.xml
> > catch throw
> >
> > bt full
> >continue
> > quit
> >This will hopefully help me to isolate this issue.
> >
>
>
> here we are!
> htt
On Sat, Dec 10, 2016 at 02:25:08AM +0100, Mattia Rizzolo wrote:
> On Fri, Dec 09, 2016 at 08:11:54PM -0500, Bill Blough wrote:
> > > >Or does anyone have other suggestions?
>
> I have one: please try to CC people (and/or MLs) sooner. I now noticed
> that you asked for
dn't help either
Thanks, I really appreciate that. I'll look through it and see if I can
find any new leads. In the mean time, would it be possible to get a
stack trace showing the exception thrown by any one of the test
programs?
Thanks,
Bill
I'd really like to get this resolved before the freeze.
Can anyone comment on the use of -Bsymbolic_functions in Ubuntu? If I
understand it correctly, it shouldn't have any effect on this, but I
have no way to test it other than another upload.
Assuming that's not it, would someone be willing t
I diffed the Debian and Ubuntu build logs, and the only difference I see
in build flags is that Ubuntu adds the -Bsymbolic_functions link flag.
Though, if I correctly understand the description of the flag, then I
don't think that's related.
As for package version differences, the only signfician
I looked at it briefly, but had to refocus on other issues before I
could really get anywhere. I'll get it sorted out and/or forwarded
shortly.
Thanks for the ping!
On Thu, Nov 03, 2016 at 04:10:27PM -0400, Sandro Tosi wrote:
> On Mon, 8 Aug 2016 13:24:48 + Mattia Rizzolo wrote:
> > source:
e pointless to remove it from testing due to this.
The popcon server neer promised that all-popcon-results.txt.gz was a
valid UTF8 file. Software must not assume that.
Please reassign to python-popcon.
Cheers,
--
Bill.
Imagine a large red swirl here.
uild-indep-stamp' failed
> make: *** [build-indep-stamp] Error 1
>
> [..]
Thanks, thi is a test-suite failure. I just reported it upstream.
Cheers,
--
Bill.
Imagine a large red swirl here.
On Wed, Jun 15, 2016 at 02:09:05PM +0200, Gregor Jasny wrote:
> Hello Bill and Ondřej,
>
> Do you know how to properly detect jpeg_mem_src presence in libjpeg(turbo)?
>
> Since the transition to jpegturbo my package FTBFS:
>
> On 14/06/16 20:42, Chris Lamb wrote:
>
not sure what you mean by that.
Users upgrading from wheezy can have locally built binaries that depend
on libjpeg8.
In any case, packages removal is not done by filling serious bug to them.
Cheers,
--
Bill.
Imagine a large red swirl here.
config.h seems to be shipped in /usr/include/x86_64-linux-gnu/gap, but
> #include "config.h"
> doesn't work...
I am downgrading this because the only supported use (gac) works fine.
Anyway, I will upload a fixed version shortly.
Cheers,
--
Bill.
Imagine a large red swirl here.
n /usr/include/x86_64-linux-gnu/gap, but
> #include "config.h"
> doesn't work...
Maybe the best fix is to add a file
/usr/include/gap/config.h
with
#include
or
#include
(and in this case rename
/usr/include/x86_64-linux-gnu/gap/config.h to
/usr/include/x86_64-linux-gnu/gap/config-arch.h
)
Cheers,
--
Bill.
Imagine a large red swirl here.
On Mon, Apr 04, 2016 at 06:07:30PM +0200, Julien Cristau wrote:
> On Mon, Apr 4, 2016 at 17:55:40 +0200, Bill Allombert wrote:
>
> > On Mon, Apr 04, 2016 at 05:11:01PM +0200, Julien Cristau wrote:
> > > Package: gap-dev
> > > Version: 4r7p9-1
> > > Severity
sr/include/x86_64-linux-gnu/gap, but
> #include "config.h"
> doesn't work...
Hello Julien,
I agree, but do you have actual code that include ?
Cheers,
--
Bill.
Imagine a large red swirl here.
On Mon, Jan 25, 2016 at 09:17:40PM +0100, Bill Allombert wrote:
> On Mon, Jan 25, 2016 at 07:00:51PM +, Michael Tautschnig wrote:
> > Package: debian-policy
> > Version: 3.9.6.1
> > Severity: serious
> > Usertags: goto-cc
> >
> > During a rebuild of al
issues:
- First debian-policy should build-depends directy on sp since the main
Makefile call nsgmls
- Second it might be a good time to migrate to openjade and opensp.
Thanks for your report!
--
Bill.
Imagine a large red swirl here.
iced your package failed to install. As
> per definition of the release team this makes the package too buggy for
> a release, thus the severity.
Hello Andreas,
This is a duplicate of #798941.
> Ship the missing directory in the package, s.t. dpkg takes care of creation
> and removal.
1 - 100 of 598 matches
Mail list logo
