control: severity -1 important
I agree, thanks for noting that as well. Let's see if I do this
correctly, I always have problems recalling the details of operating
with cont...@bugs.debian.org.
OpenPGP_signature
Description: OpenPGP digital signature
No problem!
Yes, it was more of a philosophical issue. That is the reason why I am
leaving this bug report open, in case we get a patch in time or if some
dependency really needs this plugin.
Regards,
Alberto
OpenPGP_signature
Description: OpenPGP digital signature
Hi, those are currently my thoughts as well.
I'm going to prepare a release like that, and we can see if any of the
reverse dependencies is actively using this plugin; maybe some games as
openmw are displaying movies, we will see.
Regards,
Alberto
OpenPGP_signature
Description: OpenPGP dig
Hi PaulLi,
this is highly appreciated. Thanks a lot for your effort!
I have stored the patch in the repo for reference:
https://salsa.debian.org/openscenegraph-team/openscenegraph-3.2/-/commit/d5babb29f1233a9b111be88fd1037aebb5211c54
Regards,
Alberto
On 20/9/22 19:56, Ying-Chun Liu (PaulLiu
Package: biboumi
Followup-For: Bug #957037
I have checked that current upstream (9.0) builds flawlessly, and made my
release available at https://salsa.debian.org/aluaces-guest/biboumi .
Can I be sponsored so we can upload to at least experimental?
Thanks!
Hi,
> Please do a source-only upload to unstable
Yes, I always do, including this release. But this time there was some
hiccup on the ftp queue that silently held the release, so the last
thing I tried was to see if the source-only upload was being the culprit.
> and coordinate transitions in
>
Source: fotoxx
Version: 20.08-1
Severity: grave
Justification: renders package unusable
When starting the program, it checks if "dcraw" executable is found,
and if that it not the case, the program is closed, hence the severity
of the bug report.
The
severity 945875 normal
thanks
Adjusting severity for openscenegraph.
On 27/3/20 10:57, Bret Curtis wrote:
> Man, it's be in there a month. It would be a pity to see OSG be broken
> in Buster, but hopefully we get it in before Ubuntu's LTS 20.04 Focal
> release. :/
>
> I hope it gets uploaded soon.
Well, you know that people have lives outside this scene :-)
Never
On 27/3/20 8:26, Bret Curtis wrote:
> The best way forward in resolving this bug is to get OpenSceneGraph
> package bumped to 3.6.5 right away. This requires the help of Alberto
> Fernández, it's package maintainer.
> https://tracker.debian.org/pkg/openscenegraph
Him, OSG 3.6.5 is ready
(https://s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA384
Andreas Beckmann writes:
> Source: openscenegraph-3.4
> Version: 3.4.1+dfsg1-5
> Severity: serious
> Tags: sid
>
> with openscenegraph 3.6 uploaded to sid, should the now older
> openscenegraph-3.4 be removed?
Yes, please! :-)
-BEGIN PGP SIGNAT
Thank you for the report.
The plan is to remove this package altogether from the archive and
replace it with openscenegraph.
I am going to fill the bug reports for the rdeps, and then ask for the
removal of 3.4.
Regards,
Alberto
On 11/11/19 10:32, Gianfranco Costamagna wrote:
> Source: opensce
>See `dak rm -Rn openscenegraph-3.4` on mirror.ftp-master.debian.org.
If somebody can do it, I would be grateful. I am a DM and I lack the required
permissions.
Hi, openscenegraph-3.4 can be removed from the archive safely.
Initially we planned to supersede it with src:openscenegraph-3.6, but we
are finally updating the original src:openscenegraph package.
The release is ready and waiting for being uploaded:
https://salsa.debian.org/openscenegraph-team/o
On 18/8/19 9:02, Sebastiaan Couwenberg wrote:
> On Sat, 23 Sep 2017 11:47:59 +0200 "Manuel A. Fernandez Montecelo" wrote:
>> This package will be removed after rdeps migrate to openscenegraph-3.4 or a
>> later version (which does support Qt5), or rdeps are removed, or if nothing
>> else, when the
severity -1 normal
thanks
Sorry, I misread the warning (not error) message.
Package: hotspot
Version: 1.1.0+git20180816-2
Severity: grave
Justification: renders package unusable
Dear Maintainer,
when capturing or reading laready existent "perf.data" files, Debian's
hotspot does not shown any information in any tab, except for the
graph showing the CPU use. Upstream perf
Hi, Lisandro:
On 3/12/18 22:55, Lisandro Damián Nicanor Pérez Meyer wrote:
> Hi Alberto!
>
> El lun., 3 dic. 2018 09:48, Alberto Luaces <mailto:alua...@udc.es>> escribió:
>
> Package: clazy
> Version: 1.4-3
> Severity: grave
> Justif
Source: collada-dom
Severity: serious
Tags: patch upstream
Justification: fails to build from source (but built successfully in the past)
Dear Maintainer,
Since the package openscenegraph-3.4 now depends on collada-dom, its FTBFS on
kfreebsd-* makes it unavailable as well.
The fix is really str
Package: borgbackup
Version: 1.1.3-2
Severity: critical
Tags: upstream
Justification: causes serious data loss
Dear Maintainer,
just in case you missed it, there is a upstream warning about data
loss when using "check --repair" on 1.1.x series:
https://mail.python.org/pipermail/borgbackup/2017q4
Package: heaptrack
Version: 1.0.0-1
Severity: grave
Justification: renders package unusable
Dear Maintainer,
sorry I cannot be of more help since I was merely evaluating the
package, but when I try to trace the execution of any program, I get
the error:
$ heaptrack /bin/ls
Could not find heaptra
bret curtis writes:
> With the attached patch to OSG, I can get it to compile on armhf with
> GLESv1 (libgles1-mesa-dev). It disables GLESv2 however, I got an error
> while they were both enabled.
>
> I installed the resulting packages on my RPi2 without a problem and
> got OpenMW to compile on th
Andreas Beckmann writes:
> On 2016-09-27 12:12, bret curtis wrote:
>> To put it simply, upstream (OpenMW) has no plans to support GLESv2 at
>> this time. Since OSG-3.4 for armhf is compiled only for GLESv2, this
>> complicates things drastically and at this point I'm in over my head.
>
> IIRC, qui
Source: cal3d
Followup-For: Bug #811667
I spoke too soon: recent code does not show those errors, but the rest
does have them.
Anyway, here is a patch that solves the issue.
diff -ruN cal3d-0.11.0/src/cal3d/loader.cpp cal3d-0.11.0-changes/src/cal3d/loader.cpp
--- cal3d-0.11.0/src/cal3d/loader.cpp
Upstream's SVN has fixed this, however there are no new releases. We
can either cherry pick those changes (just substituting false by 0) or
use the tip of the repository.
"Manuel A. Fernandez Montecelo" writes:
> Hi all,
>
> 2015-12-13 15:33 GMT+00:00 Sebastiaan Couwenberg :
>> On Wed, 28 Oct 2015 16:02:40 +0100 Matthias Klose wrote:
>>> For the latter two options, please see a patch at
>>> http://launchpadlibrarian.net/222944251/openscenegraph_3.2.1-7ubuntu2_3.2.
Package: libqtgui4-perl
Version: 4.8.4-1.1+b1
Severity: grave
Justification: renders package unusable
Dear Maintainer,
The QtGui4 Perl module cannot be used since merely loading it raises an error:
Code:
use QtCore4;
use QtGui4;
Result:
defined(@array) is deprecated at
/usr/lib/x86_64-linux-
Hi,
in the meantime, it is easier to set
OSG_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu/
in your environment.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Reinhard Tartler writes:
> On 18.05.2014 09:00, Manuel A. Fernandez Montecelo wrote:
>> 2014-05-18 12:10 GMT+01:00 Reinhard Tartler :
So, can you please remove that change in the NMU, if you want to keep
the NMU at all?
>>>
>>> Sure, I've just canceled the NMU.
>>
>> Thanks.
>>
>>
"Rebecca N. Palmer" writes:
>> That's why I'm not so
>> keen on uploading a RC again, given the grief that caused the last one.
>> Maybe we can just patch 3.2.0 and then wait for the 3.2.1,
>
> If you mean real 3.2.0 as opposed to the current 3.2.0rc, that could
> be a good compromise: it has sona
"Rebecca N. Palmer" writes:
> Sorry for not notifying you earlier; given the names on the git
> commits, I thought Alberto was effectively the maintainer and you his
> sponsor.
Hi, I plan to be the maintainer, but I'm not a DM yet, and so I rely on
the expertise of Manuel in order to make the re
Hi Rebecca,
"Rebecca N. Palmer" writes:
> The url_* functions were removed in libav 9 (having been deprecated in
> 0.8
> http://libav.org/doxygen/release/0.8/avio_8h.html#af4bc39f7600ed162ad8f35e5e15bcd9d
> ), hence this bug. The attached should fix it, but has not been
> tested.
>
Thanks for t
Loic Dachary writes:
> On 09/06/2011 10:35 AM, Alberto Luaces wrote:
>> Hi,
>>
>> this is fixed in the latest version from upstream. I have added a line
>> to the changelog in order to close the bug report.
>>
>> Loic, could you upload the 3.0.1-1 version
Hi,
this is fixed in the latest version from upstream. I have added a line
to the changelog in order to close the bug report.
Loic, could you upload the 3.0.1-1 version found in the git repository,
please?
Regards,
Alberto
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
Petr Salinger writes:
>>> your package no longer builds on kfreebsd-*:
>>> | [ 87%] Building CXX object
>>> applications/present3D/CMakeFiles/application_present3D.dir/Cluster.o
>>> | cd
>>> /build/buildd-openscenegraph_2.9.11-1-kfreebsd-amd64-jXKFmU/openscenegraph-2.9.11/build/osg/applications/
Cyril Brulebois writes:
> Source: openscenegraph
> Version: 2.9.11-1
> Severity: serious
> Justification: FTBFS
> User: debian-...@lists.debian.org
> Usertags: kfreebsd
>
> Hi,
>
> your package no longer builds on kfreebsd-*:
> | [ 87%] Building CXX object
> applications/present3D/CMakeFiles/appl
Hi Ben,
Ben Hutchings writes:
> Have you tested Linux 2.6.31 yet? This is the current version in
> unstable.
I tried yesterday that .deb from Sid. Blender keeps segfaulting and
WorldOfGoo shows corrupted textures and then hangs. Luckily, I could be
able to use Alt+SysReq S,U,B in order to avoid
Hello,
I also happen to suffer from the same bug. Same card, the Mobility
Radeon 7500, but different laptop: ThinkPad R51.
glxgears works with a similar warning to the one already posted:
*WARN_ONCE*
File radeon_tcl.c function radeo
Sorry, I forgot to say that those two CMake flags should only be used for the
armel build.
Regards,
Alberto
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Hello,
I have found a solution. There was no help on the CMake side, as I wrote some
days ago, as you can only operate on the linking flags, but not append new
libraries to the proccess.
So I went the linker route and found the "--whole-archive" option, that forces
the linker to add all the ob
Hi Robert and Loic,
On Tuesday 26 May 2009 11:23:15 you wrote:
> One can set the flags by doing setting the CMAKE_CXX_FLAGS either
> using ccmake ., or via the command line invocation of cmake . i.e.
>
> cmake . -DCMAKE_BUILD_TYPE=Release -DCMAKE_CXX_FLAGS="-lgcc_s -lgcc"
>
> Would this be worka
I just appended the libraries to my test library:
debian-armel:~# nm foo.o | grep __sync_bool_compare_and_swap_4
U __sync_bool_compare_and_swap_4
debian-armel:~# g++ -shared foo.o -o libfoo.so -lgcc_s -lgcc
debian-armel:~# nm -D libfoo.so | grep __sync_bool_compare_and_swap_4
debian-armel
El Domingo 24 Mayo 2009ES 18:10:11 Loic Dachary escribió:
> If you come up with a way to disable this with a CMake
> option, I'll set it for armel only in the upcoming 2.8.1 package. As
> long as it does not change the functionalities (only speed), it is
> acceptable.
Thanks :) Indeed I had writte
El Lunes 18 Mayo 2009ES 17:53:13 Alberto Luaces escribió:
> El Lunes 18 Mayo 2009ES 13:55:58 Loic Dachary escribió:
> > Based on your research it seems that we need to exclude armel from the
> > list of supported arch for OpenSceneGraph for the time being. Do you
> > see anoth
Hello,
this is finally the patch that came through upstream's SVN:
1 - openscenegraph.pc left untouched for backward compatibility reasons.
2 - Renaming of all the new .pc files from openscenegraph-lib.pc to
openscenegraph-osgLib.pc (being osgLib the real name of the library).
3 - Creation of a
El Lunes 18 Mayo 2009ES 13:55:58 Loic Dachary escribió:
> Based on your research it seems that we need to exclude armel from the
> list of supported arch for OpenSceneGraph for the time being. Do you
> see another solution ?
Yes, I'm following now Peter's suggestion, so I have now a "qemulated" ar
El Lunes 18 Mayo 2009ES 02:37:15 peter green escribió:
> >- It is almost a shoot in the dark, since we cannot test in a fast way
> > if the fix is working (it seems that for armel the latency is almost
> > two months).
>
>
>
> > Suggestions?
>
> There is always qemu,
Package: openscenegraph
Version: 2.4.0-1.1
Severity: serious
Justification: no longer builds from source
At last, the armel build of 2.8.0-4 took place on May 10th. However it
failed because the following error when building the first program on
the suite that uses the library, osgviewer:
/usr/b
El Martes 12 Mayo 2009ES 18:16:03 Loic Dachary escribió:
> Alberto Luaces wrote:
> > I think I have this done. Please find attached a patch for the root
> > CMakeLists.txt and a tarball with all the .pc.in files to be
> > deployed in the OpenSceneGraph/packaging/pkgconfig
I think I have this done. Please find attached a patch for the root
CMakeLists.txt and a tarball with all the .pc.in files to be deployed in the
OpenSceneGraph/packaging/pkgconfig directory.
Regards,
Alberto
--- CMakeLists.txt~ 2009-02-12 11:17:41.0 +0100
+++ CMakeLists.txt 2009-05-12 1
HI,
another option would be to split the .pc file into smaller chunks, one per OSG
library. This way, prograns linked to OSG won't have unneeded references as
well.
In this week I'm submitting this to upstream and here as well as a patch.
Regards,
Alberto
--
To UNSUBSCRIBE, email to debia
Hello,
You can specify your library postfix to CMake at configuration time with the
LIB_POSTFIX variable. Setting it to a null value, e.g.
cmake -DLIB_POSTFIX="" .
makes CMake install built libraries at $(prefix)/lib instead of
$(prefix)/lib64 on 64bit platforms. I have tested it.
Regards,
A
52 matches
Mail list logo