Bug#1037894: webkit2gtk: ftbfs with GCC-13
2023-07-06 01:28 Alberto Garcia: fixed 1037894 2.40.3-2 thanks On Wed, Jun 14, 2023 at 09:32:41AM +, Matthias Klose wrote: The package fails to build in a test rebuild on at least amd64 with gcc-13/g++-13, but succeeds to build with gcc-12/g++-12. The severity of this report will be raised before the trixie release. FYI I have successfully built webkit2gtk 2.40.3-2 in a sid chroot with with gcc-13 13.1.0-7 from experimental. Also it built fine with gcc-13 in riscv64, which was rebootstrapped in the last weeks and with gcc-13 as the default compiler since the start. Build for the new archive: 2.40.5-1 (sid) Maybe-Successful 2023-08-28 19:38:30 rv-osuosl-03 2d 10h 31m 23.91 GB https://buildd.debian.org/status/logs.php?pkg=webkit2gtk=riscv64 So I think that this can be closed. Cheers. -- Manuel A. Fernandez Montecelo
Bug#1024206: marked as pending in ogre-1.9
Control: tag -1 pending Hello, Bug #1024206 in ogre-1.9 reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/games-team/ogre-1.9/-/commit/b3a8a3297e783607ce824d2aedc23f1f8b110318 d/patches: add aa0219de16e95df61c0e81586f359d07aea35fe6.patch (Closes: #1024206) Add aa0219de16e95df61c0e81586f359d07aea35fe6.patch to fix FTBFS on arm ports (Closes: #1024206) (this message was generated automatically) -- Greetings https://bugs.debian.org/1024206
Bug#1024182: ogre-1.9: Do not include in release "bookworm", out of date
Source: ogre-1.9 Version: 1.9.0+dfsg1-12.1 Severity: serious X-Debbugs-Cc: m...@debian.org This package has been outdated for a few years, nowadays 1.12 should be used. It should not be included in the next stable release, bookworm. -- Manuel A. Fernandez Montecelo
Bug#1023529: subversion: FTBFS: segfault in Python tests with SWIG 4.1.0
Package: subversion
Followup-For: Bug #1023529
X-Debbugs-Cc: m...@debian.org, 1023529-submit...@bugs.debian.org
Hi,
I built a version of the package with the mentioned patch (debdiff attached), it
built correctly and passed all tests.
This was in riscv64, where the problem was detected, but I expect that it would
apply to all arches.
Hope that helps.
--
Manuel A. Fernandez Montecelo
diff -Nru subversion-1.14.2/debian/changelog subversion-1.14.2/debian/changelog
--- subversion-1.14.2/debian/changelog 2022-07-12 16:03:54.0 +0200
+++ subversion-1.14.2/debian/changelog 2022-11-08 10:57:37.0 +0100
@@ -1,3 +1,10 @@
+subversion (1.14.2-3.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Patch to fix "FTBFS: segfault in Python tests with SWIG 4.1.0" (Closes:
#1023529)
+
+ -- Manuel A. Fernandez Montecelo Tue, 08 Nov 2022 09:57:37
+
+
subversion (1.14.2-3) unstable; urgency=medium
* Re-enable the ability to store plaintext passwords (Closes: #995692)
diff -Nru
subversion-1.14.2/debian/patches/8ff4cfd06ce554e9df31a088c9d09f45278c6de4.patch
subversion-1.14.2/debian/patches/8ff4cfd06ce554e9df31a088c9d09f45278c6de4.patch
---
subversion-1.14.2/debian/patches/8ff4cfd06ce554e9df31a088c9d09f45278c6de4.patch
1970-01-01 01:00:00.0 +0100
+++
subversion-1.14.2/debian/patches/8ff4cfd06ce554e9df31a088c9d09f45278c6de4.patch
2022-11-08 10:57:37.0 +0100
@@ -0,0 +1,61 @@
+From 8ff4cfd06ce554e9df31a088c9d09f45278c6de4 Mon Sep 17 00:00:00 2001
+From: Yasuhito Futatsuki
+Date: Tue, 20 Sep 2022 12:57:06 +
+Subject: [PATCH] swig-py: Fix conditionals by SWIG version and by Python
+ version for proxy code.
+
+We are using different code for proxy object, by Python version and by SWIG
+version. The distinguish between Python 2 and Python 3 was done by SWIG
+macro "SWIGPYTHON_PY3". However, the macro was dropped since SWIG commit
+a343b7e[1], between SWIG 4.0.2 release and upcoming SWIG 4.1.0 release.
+
+As we already dropped support for the combination of SWIG >= 4.0 and Python 2,
+we should detect Python 2 only in SWIG < 4.0 case. So we can rely on the macro
+only in the case.
+
+* subversion/bindings/swig/include/proxy.swg ():
+ Reorder the conditionals distinguish SWIG versions and Python versions,
+ as described above.
+
+Found by: Jitka Plesnikova (jplesnik {_AT_} redhat.com)
+
+Suggested by: Julien Schueller (schueller {_AT_} phimeca.com) [2]
+
+[1]
https://github.com/swig/swig/commit/a343b7e254567a64761bc1be7dc55b7b7424ec52
+[2] https://github.com/swig/swig/issues/2373#issuecomment-1250997124
+
+
+git-svn-id: https://svn.apache.org/repos/asf/subversion/trunk@1904167
13f79535-47bb-0310-9956-ffa450edef68
+---
+ subversion/bindings/swig/include/proxy.swg | 4 +---
+ 1 file changed, 1 insertion(+), 3 deletions(-)
+
+Index: subversion-1.14.2/subversion/bindings/swig/include/proxy.swg
+===
+--- subversion-1.14.2.orig/subversion/bindings/swig/include/proxy.swg
subversion-1.14.2/subversion/bindings/swig/include/proxy.swg
+@@ -66,7 +66,6 @@
+ fn()
+
+ %}
+-#if defined(SWIGPYTHON_PY3)
+ #if SWIG_VERSION >= 0x04
+ %pythoncode %{
+ # -classic and -modern options have been dropped and this variable
+@@ -76,7 +75,7 @@
+ _set_instance_attr =
_swig_setattr_nondynamic_instance_variable(object.__setattr__)
+
+ %}
+-#else
++#elif defined(SWIGPYTHON_PY3)
+ %pythoncode %{
+ # SWIG classes generated with -modern do not define this variable
+ try:
+@@ -90,7 +89,6 @@
+ _set_instance_attr = _swig_setattr_nondynamic_method(object.__setattr__)
+
+ %}
+-#endif
+ #else
+ %pythoncode %{
+ # SWIG classes generated with -classic do not define this variable,
diff -Nru subversion-1.14.2/debian/patches/series
subversion-1.14.2/debian/patches/series
--- subversion-1.14.2/debian/patches/series 2022-07-12 16:03:54.0
+0200
+++ subversion-1.14.2/debian/patches/series 2022-11-08 10:57:37.0
+0100
@@ -10,3 +10,4 @@
examples-compile-instructions
workaround_EINVAL_on_kfreebsd
use-python3-as-the-interpreter-now-for-tests-not-python.patch
+8ff4cfd06ce554e9df31a088c9d09f45278c6de4.patch
Bug#936777: k3d: Python2 removal in sid/bullseye
Hi, On Sun, 10 Apr 2022 at 22:04, Moritz Mühlenhoff wrote: > > Revisiting this two years later; I really think k3d should be removed now? > Nothing changed upstream and at this point it's uninstallable in unstable > for many other libraries besides Python 2: > > - > The following packages have unmet dependencies: > k3d : Depends: libboost-program-options1.67.0 but it is not installable >Depends: libboost-python1.67.0 but it is not installable >Depends: libboost-regex1.67.0 (>= 1.67.0-10) but it is not installable >Depends: libcgal13 but it is not installable >Depends: libopenexr24 (>= 2.3.0) but it is not installable > E: Unable to correct problems, you have held broken packages. > - Indeed, I paid attention to your other bug report (sorry but I hadn't seen this yet, terrible months for me and huge backlog) and sent the necessary incantations to control@ to ask for removal, I hope. If upstream keeps inactive there's not much that we can do at this point. Thanks for keeping an eye on this! -- Manuel A. Fernandez Montecelo
Bug#1016983: Should k3d be removed?
Hi Moritz, On Wed, 10 Aug 2022 at 22:33, Moritz Muehlenhoff wrote: > > Source: k3d > Version: 0.8.0.6-8 > Severity: serious > > Your package came up as a candidate for removal from Debian: > > - Python 2 will finally be removed in Bookworm and there's no > upstream porting activity > - Last upload four years ago > - Multiple other FTBFS issue > > If you disagree and want to continue to maintain this package, > please just close this bug (and fix the open issues). > > If you agree with the removal, please reassign to ftp.debian.org > by sending the following commands to cont...@bugs.debian.org: > > -- > severity $BUGNUM normal > reassign $BUGNUM ftp.debian.org > retitle $BUGNUM RM: -- RoM; > thx > -- > > Otherwise I'll move forward and request it's removal in a month. Thanks, I'll ask for removal because upstream is basically dead and hadn't moved when I requested to migrate away from GTK2 and Python2... I very much doubt that there's any advance before the freezes... https://github.com/K-3D/k3d/issues/38 https://github.com/K-3D/k3d/issues/30 Cheers. -- Manuel A. Fernandez Montecelo
Bug#1012895: cwidget RC bug: Please upload or grant me cwidget team membership on Salsa
Hi, On Thu, 4 Aug 2022 at 18:03, Axel Beckert wrote: > > Hi Manuel, > > TL;DR: Please grant me cwidget team membership on Salsa so we don't > have to NMU it. Or just do an upload of cwidget with the patch from > #1015925. > > I know you're busy with RISC-V and other stuff, but please do me a > small favour and add me to the cwidget team on Salsa, probably via > https://salsa.debian.org/groups/cwidget-team/-/group_members Yeah, I dedicate my stuff mostly to RISC-V because I have nothing to spare in the last few years, and even there I'm lacking :-( I had seen this from pabs but will not have time at least until mid next week, so better if you do it and have permissions in general anyway, as you say. Thanks both of you, pabs and abe, for taking care! -- Manuel A. Fernandez Montecelo
Bug#936777: k3d: Python2 removal in sid/bullseye
Hi! Em 26 de mai. de 2020 às 20:43, Moritz Mühlenhoff escreveu: > > On Wed, Sep 04, 2019 at 12:10:39AM +0200, Manuel A. Fernandez Montecelo wrote: > > Control: forwarded -1 https://github.com/K-3D/k3d/issues/38 > > > > Thanks for the report. Asking upstream about their plans and best > > course of action. > > Given upstream's reply at https://github.com/K-3D/k3d/issues/38 this > seems unlikely to get ported, let's remove k3d? Basically I'd like to extend its life in Debian and keep users using this package rather than having to build the version themselves, as long as it doesn't become a big burden for Debian -- when it does sure, let's drop it, and if the moment is now, so be it. This package is in a bad situation with Python2 and GTK dependencies, but this is not the kind of application like a media player or similar for which there are a gazillion alternatives with more or less the same features -- this is a pretty specialized piece of software and migration to some other tool can be a huge undertaking and might not always be possible. If the relevant Python2 packages are going to be removed imminently, that's OK, we can remove it now. And in any case, this package should prevent the removal of Python2 if it's one of the last dependencies. But if Python2 it's to be held for a few months/years because other important/popular packages are not migrated yet (gnat-gps, kodi?), and even if only to keep it for unstable, I'd prefer to remove this package only when Python2 is removed. Cheers and thanks for your work. -- Manuel A. Fernandez Montecelo
Bug#950926: ember: Using packages to install "snap" packages is not a correct use of the packaging system
or similar and I failed to notice (which can easily happen, I have not been very active lately on many fronts). For games, most of the cases that I know of in which we have games in contrib is because of free game engines or "clones" that need non-free data from the original games or similar, not "snaps" or flatpaks or similar. (I have the impression that pabs misunderstood the intention and was talking about upstream providing alternatives to snap, not Debian, but let's not enter that territory.) > > If users want to install Snap packages, they can always do so on their own. > > They can. I'm just trying to provide a transition path that will > eventually lead to the main packaging of the updated upstream software. What I am concerned about is that you're susbtituting a normal package for a snap package and people might acquire it by upgrading it without any notice, that's why I am raising the flag. So, as I see it, while you provide a convenience to those who are OK with it, you're providing a semi-hidden *inconvenience* to people who don't want it to happen. I know that your intention is to help those who want to keep Ember installed and are OK with a snap package, but I wanted to raise the flag and protect users from installing stuff without intending it and without much of a notice. At least, I would be surprised if that would happen to me, that's why I am raising it. Cheers. -- Manuel A. Fernandez Montecelo
Bug#950926: ember: Using packages to install "snap" packages is not a correct use of the packaging system
Package: ember Version: 0.8.0~snap1 Severity: serious Hello, I don't think taht using this package as an empty shell and a gateway to install the "snap" package [1] is a valid use of the packaging system. Otherwise, if this was an accepted practice, we could start to have many packages which are just a way to install snap packages, which can easily contain security vulnerabilities and install not free software, specially if the version is not restricted in some way. And this not generally expected by users of Debian, IMO. If users want to install Snap packages, they can always do so on their own. So please reconsider and either package the game properly or drop this package altogether. [1] https://salsa.debian.org/games-team/ember/blob/master/debian/ember.preinst Cheers. -- Manuel A. Fernandez Montecelo
Bug#875075: [openscenegraph] Future Qt4 removal from Buster
Hi, Em sáb, 12 de out de 2019 às 13:23, Sebastiaan Couwenberg escreveu: > > I suggest to first update src:openscenegraph to 3.6. > > Once that's in unstable file bugreports for the src:openscenegraph-3.4 > rdeps to have them migrate to 3.6. I uploaded the new version on Alberto's behalf, initially to experimental. Hoping that it doesn't take too long to pass NEW and that everything goes well, but then the move to unstable can be immediate. Cheers. -- Manuel A. Fernandez Montecelo
Bug#935615: [Aptitude-devel] Bug#935615: aptitude: FTBFS on amd64
Hi, Em dom, 25 de ago de 2019 às 16:27, Axel Beckert escreveu: > > Hi Manuel, > > Ivo De Decker wrote: > > A binnmu of aptitude in unstable fails on amd64: > > > > https://buildd.debian.org/status/package.php?p=aptitude > > Do you happen to know if any of your recent commits to the master > branch already fixes this issue? I haven't found any which looks > fitting on a first glance... > > If you can pinpoint one or more commits, I can cherry pick them and do > a quick upload to fix this issue. Actually the more direct cause to the build error it's commit 2591a1d9069eb2e75087737c25b41449b68bd248 in cwidget. I worked on it in May/June, along with other changes in cwidget, but then it took a while in the NEW queue to get uploaded to experimental, so the window of opportunity for me to work on it went away... Maybe with that patch to cwdiget is enough, but maybe not; there are more changes needed for Boost for example, not sure what's the default version of boost now, but if not now the adaptation will be needed soon. More in general, what it needs to happen is to move cwidget 0.5.18-1 to unstable (as -2 or whatever), then rebuild aptitude against it (would be a transition, but aptitude is the only package depending on cwidget), and releases cwidget 0.5.19 and aptitude 0.8.12 as well -- it contains fixes for the upcoming apt 1.9 and other things. Maybe I can start by moving cwidget to unstable and either binNMUing or releasing the new aptitude version? Cheers. -- Manuel A. Fernandez Montecelo
Bug#923365: ftgl: FTBFS in sid (LaTeX error)
> Big oops! Sorry, I have now double-checked and the report was based on > a build log dated 2019-02-26, but apparently it took a while for me to > actually submit the bug. The underlying bug in texlive was fixed in > the meantime. No problem, thanks for the re-check :) > The package is sunny everywhere here: > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/ftgl.html It was "cloudy", "stormy" or whatever the appropriate term, until yesterday, I checked when writing my last email. But yeah, better to have a false-positive than to have an undetected FTBFS for months during the freeze, so thanks again for checking and the reporting ;-) -- Manuel A. Fernandez Montecelo
Bug#923365: ftgl: FTBFS in sid (LaTeX error)
Control: tags -1 + moreinfo
Hi Santiago!
2019-02-26 23:28 Santiago Vila:
Package: src:ftgl
Version: 2.4.0-2
Severity: serious
Tags: ftbfs
Dear maintainer:
I tried to build this package in sid but it failed:
(Yes, I know that it built ok 4 hours ago, but apparently not anymore)
[...]
debian/rules binary-arch
dh binary-arch
dh_update_autotools_config -a
dh_autoreconf -a
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, '.auto'.
libtoolize: copying file '.auto/ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'
libtoolize: copying file 'm4/ltversion.m4'
libtoolize: copying file 'm4/lt~obsolete.m4'
configure.ac:31: installing '.auto/compile'
configure.ac:12: installing '.auto/config.guess'
[... snipped ...]
! Missing \cr inserted.
\cr
l.40 \end{DoxyEnumFields}
I'm guessing that you meant to end an alignment here.
! Misplaced \cr.
\cr
l.40 \end{DoxyEnumFields}
I can't figure out why you would want to use a tab mark
or \cr or \span just now. If something like a right brace
up above has ended a previous alignment prematurely,
you're probably due for more error messages, and you
might try typing `S' now just to see what is salvageable.
! Missing \cr inserted.
\cr
l.40 \end{DoxyEnumFields}
(That makes 100 errors; please try again.)
Here is how much of TeX's memory you used:
15019 strings out of 494561
215980 string characters out of 6177454
308954 words of memory out of 500
18251 multiletter control sequences out of 15000+60
61038 words of font info for 84 fonts, out of 800 for 9000
14 hyphenation exceptions out of 8191
53i,16n,92p,802b,557s stack positions out of 5000i,500n,1p,20b,8s
! ==> Fatal error occurred, no output PDF file produced!
make[4]: *** [Makefile:619: stamp-latex] Error 1
make[4]: Leaving directory '/<>/docs'
make[3]: *** [Makefile:519: all-recursive] Error 1
make[3]: Leaving directory '/<>'
make[2]: *** [Makefile:428: all] Error 2
make[2]: Leaving directory '/<>'
dh_auto_build: make -j1 "GLUT_LIBS=-lglut -lGLU -lGL -lm" returned exit code 2
make[1]: *** [debian/rules:16: override_dh_auto_build] Error 2
make[1]: Leaving directory '/<>'
make: *** [debian/rules:13: binary-arch] Error 2
dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit
status 2
(The above is just how the build ends and not necessarily the most relevant
part)
The build was made in my autobuilder with "dpkg-buildpackage -B"
and it also fails here:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/ftgl.html
where you can get a full build log if you need it.
If this is really a bug in one of the build-depends, please use reassign and
affects,
so that this is still visible in the BTS web page for this package.
This was due to bug
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921779 , as mentioned
in the changelog.
Since I saw it marked as closed, I enabled the PDF doc again and it
worked, despite the bug in the documentation generator not having
actually been fixed at the time.
I don't know why it worked, if due to older versions than the ones
affected being used, or something else. The texlive maintainer mentions
"clean up the mess due to delayed acceptance" and closing it for a
second time yesterday, so I don't know what really happened.
Also, the network of mirrors had problems and haven't been updated for a
couple of days, including some buildds, so it's possible that this might
have played a role?
In any case, it built for me at the time of uploading, it built in
almost all buildds except unimportant ones, and I just tested and it
builds for me again locally with git-pbuilder and an up-to-date chrrot,
so I think that everything is fine now?
Thanks for caring!
--
Manuel A. Fernandez Montecelo
Bug#914153: Update to version 2.3.0-3 breaks Megaglest
Em qua, 21 de nov de 2018 às 01:54, Manuel A. Fernandez Montecelo escreveu: > > Hi Evgeny, > > 2018-11-19 23:44 Evgeny Kapun: > >Package: libftgl2 > >Version: 2.3.0-3 > > > >After updating libftgl2 from version 2.1.3~rc5-5 to version 2.3.0-3, text > >rendering in Megaglest is broken. Text is shown correctly in menus, but text > >displayed in the game itself is replaced by white rectangles. > > Thanks for the report. > > Any idea of what's going on, Frank? > > For me it works in some menus, there are white squares in others. zaz, > another application using ftgl, seems to work fine, while critterding > also shows white squares. Hi again Evgeny, With the upload of the new upstream 2.4.0-1 I think that this issue will be fixed and this bug will be closed soon. Please let us know or reopen if you still experience similar problems. Cheers. -- Manuel A. Fernandez Montecelo
Bug#914153: Update to version 2.3.0-3 breaks Megaglest
Em sex, 8 de fev de 2019 às 02:09, Manuel A. Fernandez Montecelo escreveu: > > Em sex, 8 de fev de 2019 às 01:35, Frank Heckenbach > escreveu: > > > > > I checked and everything looks all right, but I've been fighting for > > > 1+ hours because it cannot generate the ftgl.pdf documentation. > > > > Hmm, simply "./autogen.sh && ./configure && make -j" does build it > > for me (though with some warnings), using stretch. Does that work > > for you? If so, it must be something in the Debian rules; otherwise > > it seems to be difference between stable and testing which may be > > worth investigating as it may affect others too. What errors do you > > get? > > The compilation doesn't exercise some options if you don't have all > packages installed, like doxygen-gen. > > Most of the build is OK, but pdflatex chokes when genereting the .pdf. > You can see the failure here: > > http://debomatic-amd64.debian.net/distribution#unstable/ftgl/2.3.0-3/buildlog > > Note that the above is for the previous version, so it must have > happened due to changes in other Debian packages. The problem might > be in the doc though, that now fails due to more strict tools that are > not going to be changed -- not sure. > > In any case, I need to get the package built even if these tools fails > in order to get it into buster. Dropping the .pdf is the most > straightforward option to achieve it at this point, unless we can find > the real problem in the next hours, and I cannot look at it until the > weekend... OK, pushed that version. If we get around to fix the problem and in time to include it in Buster, great, if not it's a lesser problem I'd say. BTW I included a patch that I noticed, fixing a duplicated entry in projects_using_ftgl.txt, please try to apply it. Cheers. -- Manuel A. Fernandez Montecelo
Bug#914153: Update to version 2.3.0-3 breaks Megaglest
Em sex, 8 de fev de 2019 às 01:35, Frank Heckenbach escreveu: > > > I checked and everything looks all right, but I've been fighting for > > 1+ hours because it cannot generate the ftgl.pdf documentation. > > Hmm, simply "./autogen.sh && ./configure && make -j" does build it > for me (though with some warnings), using stretch. Does that work > for you? If so, it must be something in the Debian rules; otherwise > it seems to be difference between stable and testing which may be > worth investigating as it may affect others too. What errors do you > get? The compilation doesn't exercise some options if you don't have all packages installed, like doxygen-gen. Most of the build is OK, but pdflatex chokes when genereting the .pdf. You can see the failure here: http://debomatic-amd64.debian.net/distribution#unstable/ftgl/2.3.0-3/buildlog Note that the above is for the previous version, so it must have happened due to changes in other Debian packages. The problem might be in the doc though, that now fails due to more strict tools that are not going to be changed -- not sure. In any case, I need to get the package built even if these tools fails in order to get it into buster. Dropping the .pdf is the most straightforward option to achieve it at this point, unless we can find the real problem in the next hours, and I cannot look at it until the weekend... -- Manuel A. Fernandez Montecelo
Bug#914153: Update to version 2.3.0-3 breaks Megaglest
Em qui, 7 de fev de 2019 às 22:47, Frank Heckenbach escreveu: > > > The idea of using both RenderDefault() and RenderBasic() as well as > > the flag, would equally work if you have just Render() and the > > behaviour of one render or the other nested in an "if/else" based on > > the flag. Whatever makes more sense to you. I suggested it because > > in that way it is easier to change or patch the packages. > > Creating the two versions would be a lot more work, and in the end > packages need to be patched anyway. > > > Let me know when it's ready, I'll try to upload the new version within > > the same day that you have the new release ready. > > I did it, and briefly tested it with my code. > > I think you can upload it and other packages should see no change in > behaviour for now. I checked and everything looks all right, but I've been fighting for 1+ hours because it cannot generate the ftgl.pdf documentation. I'm thinking about dropping it altogether, not sure if anyone will read this doc in pdf form? What do you think? -- Manuel A. Fernandez Montecelo
Bug#914153: Update to version 2.3.0-3 breaks Megaglest
Em qui, 7 de fev de 2019 às 04:32, Frank Heckenbach
escreveu:
>
> > > My suggestion of 2018-11-25 still stands. But if you want me to do
> > > my part of it, please do your review quickly and tell me soon
> > > (or, if it's indeed necessary for the soft freeze, immediately) to
> > > avoid running out of time.
> >
> > Your plan sounds OK. Changing packages after the release, with time,
> > should be OK. I can submit automatic bug reports for the affected
> > packages.
>
> OK.
>
> > Maybe it would even be possible to have the applications set a global
> > variable, e.g.:
> >
> > enum class Render { Default = 1, Basic };
> > FTGL->setRender(Render renderType);
> >
> > and then the Render() function(s) would dispatch to either
> > RenderDefault() or RenderBasic() versions as appropriate?
>
> I generally don't much like global flags, but in this particular
> case, it might be the least painful approach.
>
> It wouldn't be foolproof. If two pieces of code, e.g. libraries,
> that are used in the same program, use Render() with different
> settings of this flag, one of them would do the wrong thing. (And
> manually changing this flag every time code from the other library
> may be used would be a maintenance nightmare.)
>
> So maybe the following is even easier to implement, while also not
> foolproof:
>
> - No RenderDefault() and RenderBasic(), just Render() as is.
>
> - A flag similar to your proposal (though I wouldn't actually call
> it "Render..."; if we aren't renaming the Render functions, we can
> use a more specific name), such as LegacyOpenGLState, and it can
> be a bool actually.
OK, sounds good. Your name is better, mine it was only an example.
The idea of using both RenderDefault() and RenderBasic() as well as
the flag, would equally work if you have just Render() and the
behaviour of one render or the other nested in an "if/else" based on
the flag. Whatever makes more sense to you. I suggested it because
in that way it is easier to change or patch the packages.
OK to the rest of the message.
Let me know when it's ready, I'll try to upload the new version within
the same day that you have the new release ready.
Cheers.
--
Manuel A. Fernandez Montecelo
Bug#914153: Update to version 2.3.0-3 breaks Megaglest
Em qua, 6 de fev de 2019 às 04:15, Frank Heckenbach
escreveu:
>
> > Em qui, 3 de jan de 2019 às 22:56, Frank Heckenbach
> > escreveu:
> > >
> > > According to https://release.debian.org/buster/freeze_policy.html:
> > >
> > > 2019-01-12 - Transition freeze
> > >
> > > Is there still time yet to get a fix in, or is it FUBAR already?
> >
> > Transition freeze means ABI changes in libraries are forbidden. We're
> > almost in soft-freeze now, more info at:
> > https://lists.debian.org/debian-devel-announce/2019/01/msg8.html
>
> So do we have time until the soft freeze on 2019-02-12 (I hope not)
> or the full freeze (2019-03-12) to get a 2.4.0 uploaded?
I believe so, yes, maybe even for the soft freeze (I am not sure how
much the time shortens for migrating packages fixing important bugs,
it varies).
> > I have to review the situation again, I completely swapped it out of
> > my memory.
>
> My suggestion of 2018-11-25 still stands. But if you want me to do
> my part of it, please do your review quickly and tell me soon
> (or, if it's indeed necessary for the soft freeze, immediately) to
> avoid running out of time.
Your plan sounds OK. Changing packages after the release, with time,
should be OK. I can submit automatic bug reports for the affected
packages.
Maybe it would even be possible to have the applications set a global
variable, e.g.:
enum class Render { Default = 1, Basic };
FTGL->setRender(Render renderType);
and then the Render() function(s) would dispatch to either
RenderDefault() or RenderBasic() versions as appropriate?
Cheers.
--
Manuel A. Fernandez Montecelo
Bug#914153: Update to version 2.3.0-3 breaks Megaglest
Em qui, 3 de jan de 2019 às 22:56, Frank Heckenbach escreveu: > > According to https://release.debian.org/buster/freeze_policy.html: > > 2019-01-12 - Transition freeze > > Is there still time yet to get a fix in, or is it FUBAR already? Transition freeze means ABI changes in libraries are forbidden. We're almost in soft-freeze now, more info at: https://lists.debian.org/debian-devel-announce/2019/01/msg8.html Sorry, I've been very busy since end of November, with unexpected work and family loads. I have to review the situation again, I completely swapped it out of my memory. Assuming that the changes in a new release do not change other behaviour, or that I can cherry pick a targeted fix for this problem, we're still good to go. Cheers, -- Manuel A. Fernandez Montecelo
Bug#917082: openscenegraph depends and build-depends on cruft packages
Hi, Em sáb, 22 de dez de 2018 às 11:33, peter green escreveu: > > package: openscenegraph > version: 3.2.2+dfsg1-2 > severity: serious > > libopenscenegraph100v5 depends on libcoin80-5 and the openscenegraph source > package bulid-depends on libcoin80-dev. These packages are no longer built by > the coin3 source package. They appear to have been replaced by libcoin80c and > libcoin-dev That must be because of a recent upload to unstable, and that the package names were not preserved, otherwise it would be a matter of binNMUing. So yep, I suppose that we'll hape to change this and hope for the best, in terms of compatibility. Thanks for the heads up, in any case! -- Manuel A. Fernandez Montecelo
Bug#914153: Update to version 2.3.0-3 breaks Megaglest
Hi Frank,
Em dom, 25 de nov de 2018 às 18:29, Frank Heckenbach
escreveu:
>
> : Perhaps the only sane way out is to add *two* new versions of each
> : rendering function, one with each behaviour, and deprecate the old
> : ones entirely. This will require changes in all applications (if
> : only to select the correct one of the two which should be easy if
> : ones knows which branch of the library they used before), but at
> : least it will be clear at compile time.
>
> That seems to me the best solution indeed. So I can offer this:
>
> - I add these two new versions for all functions involved (quite a
> few); we'd just need to agree about naming ("old" and "new" won't
> do, since in this complicated situation it's not even clear which
> one is old and which one is new; different users will view it
> differently, just like in special relativity ;), also "old" and
> "new" in function names always sounds silly; so perhaps something
> like "RenderBasic" and "RenderDefault" or so ...).
>
> - I deprecate the "Render" functions, adding a special README to
> explain things.
>
> - I change my sources to use "RenderBasic" (or whatever it'll be
> called) and test them. Other users of this fork will have to do
> the same (hopefully after seeing the deprecation warnings and
> reading that README).
>
> - I release 2.4.0 with those changes.
>
> - You put 2.4.0 in Debian. Applications using it will get the
> deprecation warnings, but should otherwise work.
>
> - A bit later, I remove the deprecated functions and release 3.0.0.
>
> - After the release of Buster, you put 3.0.0 in Debian with the
> required transitions.
>
> - Applications using it will break, but fixing them will only
> require changing "Render" to "RenderDefault" in some places
> (which are found by compiler errors). This can also be done before
> you upload 3.0.0 (as "RenderDefault" will be available in 2.4.0
> already), so the transition can be smoohter.
>
> Does this sound like a viable plan?
I am not sure if I understand. According to your plan, do the
applications in Debian using ftgl will need to change anything at all
to keep working? Because there's not much time for making changes
before the freeze, I will be quite busy for a couple of weeks at least
(so please excuse delays in replies if they don't arrive in a timely
manner), and changes of this kind usually take months to be
accomplished. It's not like we can commit changes to one or several
git repos and rebuild the packages, it's quite more complex than that.
IMO from the Debian side and for Buster there's no material time for
changes to all packages that depend on fgtl, the only practical
solutions are either to revert the change making some applications
unuseable via extra patch from Debian; or have this transition and
deprecation messages etc. in a way that existing packages don't need
changes at all.
Sorry, but I don't think that anything else works for Buster.
Cheers.
--
Manuel A. Fernandez Montecelo
Bug#914153: Update to version 2.3.0-3 breaks Megaglest
t would have to be the old behaviour, yes, because after many years behaving in that way the applications must have learned to adapt or cope, and no one knows that they have to use a different flag or invoke the method with an extra parameter. I realise that maybe this is not what you like because applications will ever remain buggy, but reallistically, some might even be abandoned upstream, so they could remain unusable forever. Cheers. -- Manuel A. Fernandez Montecelo
Bug#874727: OSG changing VRML renderer away from coin3
Em seg, 5 de nov de 2018 às 07:10, Sebastiaan Couwenberg escreveu: > On 11/5/18 12:45 AM, Manuel A. Fernandez Montecelo wrote: > > 2018-11-04 18:28 Christoph Berg: > >> > >> | Patches for both OSG packages have been submitted to use SGI Inventor > >> | instead of COIN: > >> | > >> | https://bugs.debian.org/912866 (openscenegraph) > >> | https://bugs.debian.org/912867 (openscenegraph-3.4) > > > > I am not totally opposed to that, and thanks to Bas for the patches. > > But it looks to me that the proper solution is something like what > > Bernhard posted just minutes before this message that I am replying to > > (that perhaps Christoph didn't notice, due to the timing): > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874727#96 > > Yes, the proper solution is to fix coin3. The OSG patches are meant as > an interim solution to remove the coin3 dependency from the OSG packages > and remove the threat of testing autoremoval. I think that we're not in danger at this point, at least I cannot see anything in the tracker. If the situation becomes more urgent/critical (e.g. due to being closer to the freeze) and I am not available to respond at that time in a reasonable time (2 days to a week, whatever you judge appropriate), please go ahead and fix it, unless co-maintainers (which are main maintainers really) object to it in the meantime. Thanks! -- Manuel A. Fernandez Montecelo
Bug#887712: fixed in ftgl 2.3.0-1
Hi, Em qui, 8 de nov de 2018 às 11:59, IOhannes m zmölnig (Debian/GNU) escreveu: > > (resending) > > my packages are marked for AUTORM by end of november, because they B-D > on ftgl. > i would really like to avoid having them removed from testing. Thanks for the ping, I certainly did miss the initial message, since I'm not listed as maintainer and didn't get sent an email automatically. > On Wed, 31 Oct 2018 10:10:46 +0100 =?UTF-8?Q?IOhannes_m_zm=c3=b6lnig?= > wrote: > > On Sat, 20 Oct 2018 14:49:43 +0000 m...@debian.org (Manuel A. Fernandez > > Montecelo) wrote: > > > Source: ftgl > > > Source-Version: 2.3.0-1 > > > > thanks for doing an upload of ftgl-2.3 to "experimental". > > do you have any plans, to also upload to "unstable" (so all those > > reverse-dependencies that are marked AUTORM won't get kicked out of > > Debian)? is a transition required? So I had plans to upload to unstable, but then noticed that the new upstream maintainer (in copy) changed the SOVERSION. I don't know if there's an actual break in ABI or it was just to set it and be the same as the version of the library, but in fact this will cause a transition, so it's what stopped me from uploading to unstable. I think that I asked Frank about this but didn't get a reply yet, I know that he's been busy with misc things. I suppose that we can either upload to unstable and request a transition slot, and everything will be fine, or check that the ABI didn't change and patch to keep the old SOVERSION. Would you like to help with that? I've been kept busy and without a continous stretch of time to review and deal with the issue properly, also because of other Debian duties, so I'm not sure when I'll be able to deal with that. > > (btw, where is ftgl-2.3.0 upstream? is it the > > https://github.com/ulrichard/ftgl fork?) I don't know why it's so buried in github, but Richard was not interested in being the main maintainer and as discussed in https://github.com/ulrichard/ftgl/pull/9#issuecomment-428309601 the de-facto maintainer is now Frank. Also from https://github.com/ulrichard/ftgl/ main page/README: ftgl is currently hosted at: https://github.com/frankheckenbach/ftgl Current maintainer: Frank Heckenbach Cheers. -- Manuel A. Fernandez Montecelo
Bug#874727: OSG changing VRML renderer away from coin3
Hi, 2018-11-04 18:28 Christoph Berg: Re: To markus 2018-10-05 <20181005080326.gb13...@msg.df7cb.de> > it's a packaging bug - libcoin is statically linked with libexpat, and > the version being used is outdated. So anything that uses libcoin and > libexpat will run into a segfault. > > I am not aware of any other application that uses libcoin. I noticed because PostGIS is affected via postgis B-D -> libsfcgal-dev -> libsfcgal-osg1 -> libopenscenegraph100v5 -> libcoin80v5. Looking at https://udd.debian.org/cgi-bin/autoremovals.cgi there's quite a few packages depending on coin3. So the question whether this affects freecad only or more packages is making quite a difference. There is some indirect progress on this, Sebastiaan Couwenberg has submitted patches to change OSG's VRML renderer to SGI Inventor: | Patches for both OSG packages have been submitted to use SGI Inventor | instead of COIN: | | https://bugs.debian.org/912866 (openscenegraph) | https://bugs.debian.org/912867 (openscenegraph-3.4) I am not totally opposed to that, and thanks to Bas for the patches. But it looks to me that the proper solution is something like what Bernhard posted just minutes before this message that I am replying to (that perhaps Christoph didn't notice, due to the timing): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874727#96 I think that it's a better/proper solution because: a) SGI inventor looks like not having new upstream releases for more than a decade (or them not packaged in Debian), thus presumably not a terribly good idea in general to keep packages depending on it b) Fixing a problem with crashes and embedded static expat library in Coin looks like the right thing to do anyway Cheers. -- Manuel A. Fernandez Montecelo
Bug#912617: libsdl2-image: CVE-2018-3977: do_layer_surface code execution vulnerability
Hi, Em dom, 4 de nov de 2018 às 17:28, Chris Lamb escreveu: > > > I suppose that it's better that you go ahead unless they reply > > between now and you reading this e-mail. > > Sure. From this I will go ahead and upload to sid. I've requested > access to the Salsa group so I can push my changes. I was planning to gbp-import-dsc, but if you prefer I'll grant you access, sure. > (I still await the Security Team on stable.) OK, if you need any help please tell. I might not be around much in the next days, but I will try to be responsive. Cheers. -- Manuel A. Fernandez Montecelo
Bug#912617: libsdl2-image: CVE-2018-3977: do_layer_surface code execution vulnerability
Hi Chris, Em dom, 4 de nov de 2018 às 15:48, Chris Lamb escreveu: > > Hi SDL maintainers & security team, > > > libsdl2-image: CVE-2018-3977: do_layer_surface code execution > > vulnerability > > The attached patches apply cleanly to jessie, stretch and sid > respectfully. (Looks like they reformatted their code later on.) > > I am happy to upload handle jessie, but I can also work on the > stable/sid releases too if you wish; please let me know. I am enjoying a kind of a "long weekend" / mini-holidays, could not work on it so far and will not at least for another 3 or 4 days, and since the rest of the team did not reply to the original report I suppose that it's better that you go ahead unless they reply between now and you reading this e-mail. Thanks the several people involved in the work, both for the report and patches and offer to fix! Cheers. -- Manuel A. Fernandez Montecelo
Bug#909778: libsdl2-dev: SDL_config.h no longer in cflags provided by pkg-config/sdl2-config
Hi, Em dom, 30 de set de 2018 às 16:57, Simon McVittie escreveu: > > For the short term, I'm preparing a NMU that reverts the multiarch change > and adds an autopkgtest that confirms that the package is usable, because > libsdl2-dev is currently unusable, and that's a considerably worse bug > than not being multiarch-friendly. For the record: I spoke to Simon and acked the NMU with no delay, to avoid affecting more packages. Thanks Simon for fixing this! -- Manuel A. Fernandez Montecelo
Bug#898502: ucommon: Please update symbols for riscv64 and ia64
Source: ucommon Version: 7.0.0-12 Severity: serious User: debian-ri...@lists.debian.org Usertags: riscv64 Hi, This is possibly related with #897878 (FTBFS due to symbols with GCC-8), and indeed the solution it's similar, needs an update to the symbols file, but decided to report it separately just in case. The problem of symbols mismatch already happens with gcc-7, the default compiler in unstable, for two arches: https://buildd.debian.org/status/fetch.php?pkg=ucommon=ia64=7.0.0-12=1523296684=0 https://buildd.debian.org/status/fetch.php?pkg=ucommon=riscv64=7.0.0-12=1524128306=0 Also can be seen in the main buildd page in a clear way, the same missing symbol for both ia64 and riscv64 (but different from the ones in gcc-8): https://buildd.debian.org/status/package.php?p=ucommon=sid + _ZN7ucommon6String6vscanfEPKcPv@Base 7.0.0-12 + _ZN7ucommon6String7vprintfEPKcPv@Base 7.0.0-12 So, conjecturing a bit, to me it seems likely that it actually FTBFS in all arches, only that it was not detected because the last builds for these two ones happend in the last <33 days, and for the rest many months ago (8+ months, all during the same days). It's strange that symbols change in this way with the same GCC major version, the compiler was 7.2 when compiled in the other arches. But the alternative explanation that the symbols are fine in all arches except in ia64 and riscv64 is even more improbable IMO, given the additional coincidade of build dates. I'm OK if you decide to set a lower priority, but given that it already fails in at least two arches, the possibility that it happens in others nowadays, and GCC-8 becoming the default soonish (< 3 months, if we look at what happened in previous years), made me to decide for severity "serious". Thanks and cheers. -- Manuel A. Fernandez Montecelo <m...@debian.org>
Bug#865797: signond FTBFS: symbol changes
user debian-ri...@lists.debian.org usertag 865797 + riscv64 stop Hi, 2017-06-24 23:17 Adrian Bunk: Source: signond Version: 8.59-1 Severity: serious Tags: buster sid Some recent change in unstable makes signond FTBFS: https://tests.reproducible-builds.org/debian/history/signond.html https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/signond.html FWIW I was able to build for riscv64 updating symbols with pkgkde-symbolshelper (update for all arches), debdiff attached. ia64 and riscv64 are the only ones built recently though. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com> diff -Nru signond-8.59/debian/changelog signond-8.59/debian/changelog --- signond-8.59/debian/changelog 2016-06-24 14:20:35.0 +0200 +++ signond-8.59/debian/changelog 2018-05-06 19:35:09.0 +0200 @@ -1,3 +1,10 @@ +signond (8.59-1+0.riscv64.1) unreleased; urgency=medium + + * Non-maintainer upload. + * riscv64: symbols update + + -- Manuel A. Fernandez Montecelo <m...@debian.org> Sun, 06 May 2018 17:35:09 + + signond (8.59-1) unstable; urgency=medium [ Diane Trout ] diff -Nru signond-8.59/debian/libsignon-plugins-common1.symbols signond-8.59/debian/libsignon-plugins-common1.symbols --- signond-8.59/debian/libsignon-plugins-common1.symbols 2016-06-24 14:20:35.0 +0200 +++ signond-8.59/debian/libsignon-plugins-common1.symbols 2018-05-06 19:34:49.0 +0200 @@ -1,15 +1,15 @@ -# SymbolsHelper-Confirmed: 8.59 amd64 +# SymbolsHelper-Confirmed: 8.59-1 alpha arm64 armel armhf hppa hurd-i386 i386 ia64 kfreebsd-amd64 kfreebsd-i386 m68k mips mips64el mipsel powerpc powerpcspe ppc64 ppc64el riscv64 s390x sh4 sparc64 x32 libsignon-plugins-common.so.1 libsignon-plugins-common1 #MINVER# - (optional=templinst|arch=mips64el mipsel)_Z17qRegisterMetaTypeI13QDBusArgumentEiPKcPT_N9QtPrivate21MetaTypeDefinedHelperIS3_Xaasr12QMetaTypeId2IS3_E7DefinedntsrS8_9IsBuiltInEE11DefinedTypeE@Base 8.57+20150423 +#MISSING: 8.59-1# (optional=templinst|arch=mips64el mipsel)_Z17qRegisterMetaTypeI13QDBusArgumentEiPKcPT_N9QtPrivate21MetaTypeDefinedHelperIS3_Xaasr12QMetaTypeId2IS3_E7DefinedntsrS8_9IsBuiltInEE11DefinedTypeE@Base 8.57+20150423 _Z23expandDBusArgumentValueRK8QVariantPb@Base 8.57+20150423 (optional=templinst|arch=amd64)_Z27qRegisterNormalizedMetaTypeI13QDBusArgumentEiRK10QByteArrayPT_N9QtPrivate21MetaTypeDefinedHelperIS4_Xaasr12QMetaTypeId2IS4_E7DefinedntsrS9_9IsBuiltInEE11DefinedTypeE@Base 8.57+20150423 - (optional=templinst)_ZN17QtMetaTypePrivate23QMetaTypeFunctionHelperI13QDBusArgumentLb1EE6CreateEPKv@Base 8.57+20150423 - (optional=templinst)_ZN17QtMetaTypePrivate23QMetaTypeFunctionHelperI13QDBusArgumentLb1EE6DeleteEPv@Base 8.57+20150423 +#MISSING: 8.59-1# (optional=templinst)_ZN17QtMetaTypePrivate23QMetaTypeFunctionHelperI13QDBusArgumentLb1EE6CreateEPKv@Base 8.57+20150423 +#MISSING: 8.59-1# (optional=templinst)_ZN17QtMetaTypePrivate23QMetaTypeFunctionHelperI13QDBusArgumentLb1EE6DeleteEPv@Base 8.57+20150423 (optional=templinst)_ZN17QtMetaTypePrivate23QMetaTypeFunctionHelperI13QDBusArgumentLb1EE8DestructEPv@Base 8.57+20150423 (optional=templinst)_ZN17QtMetaTypePrivate23QMetaTypeFunctionHelperI13QDBusArgumentLb1EE9ConstructEPvPKv@Base 8.57+20150423 (optional=templinst)_ZN4QMapI7QString8QVariantE13detach_helperEv@Base 8.57+20150423 - (optional=templinst)_ZN4QMapI7QString8QVariantED1Ev@Base 8.59 - (optional=templinst)_ZN4QMapI7QString8QVariantED2Ev@Base 8.59 + (optional=templinst|arch=!ia64 !riscv64)_ZN4QMapI7QString8QVariantED1Ev@Base 8.59 + (optional=templinst|arch=!ia64 !riscv64)_ZN4QMapI7QString8QVariantED2Ev@Base 8.59 _ZN6SignOn13BlobIOHandler11qt_metacallEN11QMetaObject4CallEiPPv@Base 8.57+20150423 _ZN6SignOn13BlobIOHandler11qt_metacastEPKc@Base 8.57+20150423 _ZN6SignOn13BlobIOHandler11receiveDataEi@Base 8.57+20150423 @@ -31,23 +31,26 @@ (optional=templinst)_ZN7QVectorI10QByteArrayE11reallocDataEii6QFlagsIN10QArrayData16AllocationOptionEE@Base 8.57+20150423 (optional=templinst)_ZN7QVectorI10QByteArrayE6appendERKS0_@Base 8.57+20150423 (optional=templinst)_ZN8QMapNodeI7QString8QVariantE14destroySubTreeEv@Base 8.57+20150423 + (arch=ia64 riscv64)_ZN9QtPrivate16StreamStateSaverD1Ev@Base 8.59-1 + (arch=ia64 riscv64)_ZN9QtPrivate16StreamStateSaverD2Ev@Base 8.59-1 + (optional=templinst|arch=ia64 riscv64)_ZN9QtPrivate24readAssociativeContainerI4QMapI7QString8QVariantEEER11QDataStreamS6_RT_@Base 8.59-1 _ZNK6SignOn13BlobIOHandler10metaObjectEv@Base 8.57+20150423 (optional=templinst)_ZNK8QMapNodeI7QString8QVariantE4copyEP8QMapDataIS0_S1_E@Base 8.57+20150423 _ZTVN6SignOn13BlobIOHandlerE@Base 8.57+20150423 (optional=templinst)_ZZN11QMetaTypeIdI13QDBusArgumentE14qt_metatype_idEvE11metatype_id@Base 8.57+20150423 - (optional=templinst)_ZrsI7QString8QVariantER11QDataStreamS3_R4QMapIT_T0_E@Base 8.57+20150423 + (optional=templinst|arch=!ia
Bug#853446: Patch
Control: tags -1 + pending 2017-08-26 16:59 Hilko Bengen: Control: tag -1 patch GCC-7 recognizes patches that contain the word "fallthrough" (and some variants thereof), but not misspellings. This patch fixes that. Thanks, applied now and about to do an NMU upload. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#876308: libxml2 FTBFS: rename: "Unknown option: vf"
Hi, 2017-10-15 13:24 GMT+02:00 Mattia Rizzolo <mat...@debian.org>: > On Sun, Oct 15, 2017 at 12:41:53PM +0200, Manuel A. Fernandez Montecelo wrote: >> >> libxslt needed also to add "rename" as B-D, which I added in a recent >> >> NMU. >> > >> > About that, next time please consider using the delayed queue, and for >> > packages where I'm somehow involved consider also picking the unreleased >> > changes from the git repositories :) >> >> Sorry about that Mattia. Since there almost no uploads in the last >> year (other than fixes for old suites), and the FTBFS bug open for 2 >> or 3 weeks without replies, I thought that the package was a bit >> behind in maintenance > > Yes, it is definitly under-maintained… (as libxml2 is, btw) :( > That's why, don't get me wrong, I'm very happy you NMUed it! I just > hoped you could give a notice before it landed, so I could suggest you > picked the unreleased VCS changes :) Yes, you're right. I set delayed on all my NMU uploads lately, fixing different rebootstrap/cross-compilation bugs, plus some additions. I didn't do it for the reasons explained, and also to have time to fix things if there was something wrong that needed urgent fixes (I don't always know what I'll be doing in 10~15 days; and in this case, 2~5 was bad because I would be travelling). But perhaps I should just have waited, to allow for some feedback... it's a good thing to take into account in future uploads :-) Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#876308: libxml2 FTBFS: rename: "Unknown option: vf"
2017-10-15 2:31 GMT+02:00 Mattia Rizzolo <mat...@debian.org>: > On Sun, Oct 15, 2017 at 02:01:53AM +0200, Manuel A. Fernandez Montecelo wrote: >> Maybe it needs a build-depends on "rename", which was split from the >> Perl package. > > No. > > The bug here is that the new `rename` doesn't support '-vf' as options, > but it needs to be separated as '-v -f'. > This package actually uses `prename`, not `rename`, which was only took > over last month, which is why this FTBFS has been caught so late. > >> libxslt needed also to add "rename" as B-D, which I added in a recent >> NMU. > > About that, next time please consider using the delayed queue, and for > packages where I'm somehow involved consider also picking the unreleased > changes from the git repositories :) Sorry about that Mattia. Since there almost no uploads in the last year (other than fixes for old suites), and the FTBFS bug open for 2 or 3 weeks without replies, I thought that the package was a bit behind in maintenance, so just followed the general NMU recommendation. >> I can also prepare an NMU for this package if it helps. > > On it, thanks for the buzz. Great, thanks! Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#876308: libxml2 FTBFS: rename: "Unknown option: vf"
Hi, 2017-09-20 21:42 Helmut Grohne: Source: libxml2 Version: 2.9.4+dfsg1-4 Severity: serious User: helm...@debian.org Usertags: rebootstrap libxml2 fails to build from source in sid/amd64: | make[2]: Leaving directory '/<>/libxml2-2.9.4+dfsg1/builddir/main/python2.7-dbg' | prename -vf 's/(?>/libxml2-2.9.4+dfsg1' | debian/rules:147: recipe for target 'binary-arch' failed | make: *** [binary-arch] Error 2 | dpkg-buildpackage: error: fakeroot debian/rules binary-arch gave error exit status 2 Maybe it needs a build-depends on "rename", which was split from the Perl package. libxslt needed also to add "rename" as B-D, which I added in a recent NMU. I can also prepare an NMU for this package if it helps. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#784181: [razorqt] Future Qt4 removal from Buster
2017-09-09 23:09 Lisandro Damián Nicanor Pérez Meyer: In order to make this move, all packages directly or indirectly depending on the Qt4 libraries have to either get ported to Qt5 or eventually get removed from the Debian repositories. This package can be removed when Qt4 is, see: #784181 -- razorqt: Razor-Qt dead upstream, superseded by LXQt (copying the bug report, keeping them separate at the moment) -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#784181: razorqt: Razor-Qt dead upstream, superseded by LXQt
Control: severity -1 serious Hi, 2017-09-09 5:33 GMT+02:00 Simon Quigley <tsimo...@ubuntu.com>: > Control: retitle -1 razorqt: Razor-Qt dead upstream, superseded by LXQt > Control: severity -1 grave > > Hello, > > Bump on this. razorqt has been dead upstream for several years now > (several LXQt releases have made it in Debian, even making it into > Stretch), and popcon statistics have dropped. I would like to get this > removed as part of the effort to remove Qt 4 from the archive for Buster > as announced[1]. > >> so I would just feel bad removing it from the archive at this >> point. > I don't see a reason to keep this in the archive, but I'm not the > maintainer... I don't see an upload since 2014, and since it's not > maintained upstream, there could be severe bugs or security issues in > the packaged version that have not been discovered. In my opinion this > is a compelling reason to finally drop it, and it might just be better > than keeping it in the archive. > > Thoughts? I already explained this in the bug report multiple times in different messages of this bug report. Yes, the package will have to be removed beause Qt4 is going to be removed, I already said that in the original submission. It turns out that Qt4 was not removed in 6 months time, as I expected then, and 2.5 years later is still here. Since there are no upstream releases and haven't been important bugs reported, coupled with the pending removal, there have been no strong reasons for new uploads. However, I use it on a daily basis on several computers and it works fine. There are many packages, including similar desktops/windows managers, in the same situation, and they were even shipped in the last stable (unlike razorqt). Razorqt is still more popular than other WMs, even not being in the last stable, and contrary to my expectations users didn't migrate en-masse to LXQt, popcon reports 70% of the users at the peak time in 2015. So: If Qt4 is going to be removed within a month, by all means, let's go ahead and remove razorqt now. But if the news are that it's going to be removed "in buster release cycle", which might mean even 2 years time, and perhaps even it ends up not being removed (as the announcement says) please lets this package be until it actually blocks the removal of Qt4. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#853316: aptitude: ftbfs with GCC-7
Control: tags -1 + pending Hi, 2017-01-31 10:29 Matthias Klose: Package: src:aptitude Version: 0.8.5-1 Severity: normal Tags: sid buster User: debian-...@lists.debian.org Usertags: ftbfs-gcc-7 Fix applied and pending to upload, thanks! -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#834204: libsdl1.2: Nonfree file: src/video/fbcon/riva_mmio.h
Hi Jonas, 2017-07-18 14:14 Jonas Smedegaard: Package: src:libsdl1.2 Followup-For: Bug #834204 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I have prepared an NMU and queued for release in 5 days. Attached is the diff. Thanks. I am in the midst of a snowstorm, metaphorically speaking, so I didn't have time (and neither I will have in the next few days) to review this in depth, but in principle I trust your good judgement so all fine by me, including the NMU. I made the changes in git locally, and can push that to Alioth if granted write access to the repository (my account is js). Alternatively I can put my git public somewhere for you to clone if you prefer. If you want to become a somewhat-regular contributor / maintainer the first option is preferrable, otherwise I think that the output of format-path is intended for this kind of situations, and preserves authorship and all that (?). Whatever you prefer, really. ... and big thanks for caring and fixing this bug. PS: (Would be super if you contact upstream about it, but it's fine if you don't want to get so involved. I'll try to remember in the next revision of the package). -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#784181: razorqt: Razor-Qt dead upstream, superseded by LXDE-Qt
Hi Steve,
(it's a long message, the important bits are just at the bottom).
2017-04-01 20:48 Steve Langasek:
Hi Manuel,
In May 2015, you wrote:
I plan to ask FTP-masters for removal from unstable in a few months, when
the new desktop is usable.
But then in December 2016, you wrote:
I am not sure, is there a big compelling reason to remove it, like big
security bugs? It's dead upstream but it's still working fine without
maintainance, and building in all Linux-based architectures.
You didn't quote the following paragraphs in that message, which I think
that are relevant:
"I thought that once removed from unstable and LXQt becoming ready, it
would decline in popularity measurably so we could think about
removing it... but it's not declining, even as % it's maintaining the
same levels [...]
Once it disappears from the next stable maybe people migrate to LXQt
and we see a big drop, or maybe complain that it was removed from
stable or something... but until then, since there seem to be users, I
don't have any compelling reason to remove it."
Will come back to this later...
I don't know if you find it compelling, but you have agreed that this
package should not be in the next Debian release, which is why it's removed
from testing; but by leaving it in unstable, it may still be included in
releases of derivative distributions that pull from unstable. Ubuntu is an
example of this - and for Ubuntu, we will manually remove the package - but
other distributions may also be affected.
You mention popcon as a reason for not removing the package. I guess there
are a lot of users who have the package installed because it was a
dependency of something else in the archive, and it's still installed
because there was no transition which forced it off their systems. I
wouldn't read into a high popcon count for a non-leaf package.
Some (gentle) popcon saber-rattling:
"razorqt-desktop" is not a leaf package, but "razorqt" is, only other
"razorqt-*" packages Suggest it. (That's enough to keep it installed
once it's been installed in most systems by default, I think, but
still).
"razorqt" is currently at 157, while it peaked at ~230 or so, and it's
at the same level or higher than in mid 2015 (the big GCC-5 / C++11 ABI
change):
https://qa.debian.org/popcon-graph.php?packages=razorqt_installed=on_legend=on_ticks=on_fmt=%25Y-%25m=1
In percentages it's more clear that there're less installations than in
the past:
https://qa.debian.org/popcon-graph.php?packages=razorqt_installed=on_percent=on_legend=on_ticks=on_date=_date=_date=_fmt=%25Y-%25m=1
This is similar for all packages in this collection (the graph is oddly
flattish):
https://qa.debian.org/popcon-graph.php?packages=razorqt+libqtxdg0+libqtxdg0-dev+librazorqt0+librazorqt0-dev+razorqt-data+razorqt-appswitcher+razorqt-autosuspend+razorqt-config+razorqt-confupdate+razorqt-desktop+razorqt-globalkeyshortcuts+razorqt-lightdm-greeter+razorqt-notificationd+razorqt-openssh-askpass+razorqt-panel+razorqt-policykit-agent+razorqt-power+razorqt-runner+razorqt-session_installed=on_percent=on_legend=on_ticks=on_date=_date=_date=_fmt=%25Y-%25m=1
Anyway, "razorqt-desktop" is a non-leaf packages, but only "razorqt"
Depends on it, and only other "razorqt-*" packages Recommend it.
AFAIK it's been always like this in the past, there were no external
reverse dependencies outside this group of packages.
So in light of this, since the dependencies are (and AFAIK always were
only) among razorqt packages, I think that it's reasonable to assume
that people have installed it on purpose (not pulled by other packages),
and there are people using it recently ("vote" columns).
I am glad that LXQt is in Debian now, and I would be happy to remove it
if the numbers dropped dramatically (that's what I thought that it would
happen when I wrote the message back in 2015). But as things stand,
there are still more than half the installations reported than at peak
times, so I would just feel bad removing it from the archive at this
point.
Since the release is only weeks/months away, I would like to wait and
see what happens.
Is there another way to avoid this problem for derivatives, while
maintaining it in unstable?
Cheers.
--
Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#849696: libogre-1.9.0v5: Ogre games abort on startup with “basic_string::_M_construct null not valid” / freeimage API issues
Hi,
2016-12-30 02:33 James Cowgill:
Control: severity -1 grave
Hi,
This is RC because nothing using ogre will start anymore.
On 29/12/16 21:52, Thibaut Girka wrote:
Package: libogre-1.9.0v5
Version: 1.9.0+dfsg1-7+b2
Severity: important
Any Ogre game/application (for instance, funguloids, available in Debian)
crashes with the following output:
Creating resource group General
Creating resource group Internal
Creating resource group Autodetect
SceneManagerFactory for type 'DefaultSceneManager' registered.
Registering ResourceManager for type Material
Registering ResourceManager for type Mesh
Registering ResourceManager for type Skeleton
MovableObjectFactory for type 'ParticleSystem' registered.
ArchiveFactory for archive type FileSystem registered.
ArchiveFactory for archive type Zip registered.
ArchiveFactory for archive type EmbeddedZip registered.
DDS codec registering
FreeImage version: 3.17.0
This program uses FreeImage, a free, open source image library supporting all
common bitmap formats. See http://freeimage.sourceforge.net for details
terminate called after throwing an instance of 'std::logic_error'
what(): basic_string::_M_construct null not valid
Abandon
This started happening since upgrading libfreeimage3, so this might be a bug in
it rather than in Ogre itself, but I haven't investigated any further yet.
This appears to be a regression in the Debian patch applied in
libfreeimage3 3.17.0+ds1-4.
Ogre contains this (OgreMain/src/OgreFreeImageCodec.cpp:98):
for (int i = 0; i < FreeImage_GetFIFCount(); ++i)
{
// Skip DDS codec since FreeImage does not have the option
// to keep DXT data compressed, we'll use our own codec
if ((FREE_IMAGE_FORMAT)i == FIF_DDS)
continue;
String exts(FreeImage_GetFIFExtensionList((FREE_IMAGE_FORMAT)i));
[loop body continues]
[String is typedefed to std::string]
This code assumes that FreeImage_GetFIFExtensionList will never return
NULL for values of i between 0 and FreeImage_GetFIFCount(). However in
the most recent Debian version of freeimage,
FreeImage_GetFIFExtensionList(27 / FIF_FAXG3) does return NULL.
It is unclear to me who is wrong here. The documentation does not
suggest anything about when FreeImage_GetFIFExtensionList can fail,
although the examples always check FreeImage_FIFSupportsReading before
calling it. Can any freeimage maintainer suggest the best way to fix this?
Thanks for the analysis.
The comment on the patch seems to add some light as to the cause of this
breakage:
https://anonscm.debian.org/cgit/debian-science/packages/freeimage.git/commit/?id=a67fe8c111d0de919b7a6710d4dd5efe05fbf380
++//allows adding a NULL node in order to not mess up plugin
++//numbering when some are disabled. Otherwise there will be a
++//discrepancy between FREE_IMAGE_FORMAT enumerator values and the
++//actual format.
++m_plugin_map[(const int)m_plugin_map.size()] = 0;
If freeimage plans to ship with this change and not revert it somehow,
the OGRE plugin for freeimage needs to check for the possibility of
having null nodes in this structure.
Cheers.
--
Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#849370: aptitude: Aptitude crashes with SIGABRT on install command
Control: tags -1 + moreinfo Control: severity -1 important Setting metadata correctly, at least while there's no reply... and assuming that it doesn't affect /many/ people... https://www.debian.org/Bugs/Developer#severities important a bug which has a major effect on the usability of a package, without rendering it completely unusable to everyone. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#849370: aptitude: Aptitude crashes with SIGABRT on install command
2016-12-26 11:18 Jean-Luc Coulon (f5ibh): Package: aptitude Version: 0.8.3-1+b2 Severity: grave Justification: renders package unusable -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Aptitude crashes with SIGABRT on apt-get install command line or in the "G" command in curses mode. I assume that you mean "aptitude install"? Can you please provide a backtrace of a crash with the "aptitude install"? Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#784181: razorqt: Razor-Qt dead upstream, superseded by LXDE-Qt
Hi, 2016-12-12 2:22 GMT+01:00 Jeremy Bicha <jbi...@ubuntu.com>: > I see that razorqt was removed from testing, but why not remove it > from unstable too now? I am not sure, is there a big compelling reason to remove it, like big security bugs? It's dead upstream but it's still working fine without maintainance, and building in all Linux-based architectures. I thought that once removed from unstable and LXQt becoming ready, it would decline in popularity measurably so we could think about removing it... but it's not declining, even as % it's maintaining the same levels: https://qa.debian.org/popcon-graph.php?packages=razorqt-desktop_installed=on_legend=on_ticks=on_fmt=%25Y-%25m=1 https://qa.debian.org/popcon-graph.php?packages=razorqt-desktop_installed=on_percent=on_legend=on_ticks=on_date=_date=_date=_fmt=%25Y-%25m=1 Once it disappears from the next stable maybe people migrate to LXQt and we see a big drop, or maybe complain that it was removed from stable or something... but until then, since there seem to be users, I don't have any compelling reason to remove it. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#811742: smpeg: diff for NMU version 0.4.5+cvs20030824-7.2
Hi, 2016-09-24 20:39 GMT+02:00 Sebastian Ramacher <sramac...@debian.org>: > Control: tags 811742 + patch > Control: tags 811742 + pending > > Dear maintainer, > > I've prepared an NMU for smpeg (versioned as 0.4.5+cvs20030824-7.2) and > uploaded it to DELAYED/2. Please feel free to tell me if I > should delay it longer. Hmm, somehow I missed this RC bug in the last few months when tending to Debian things -- although, due to time constraints, I've been less active than in the last few years. It's fine from my side, thanks! Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#838516: FTBFS: conflicts between build dependencies
2016-09-22 3:26 GMT+02:00 Paul Wise <p...@debian.org>: > On Wed, 2016-09-21 at 21:38 +0200, Joachim Reichel wrote: > >> Build-Depends: [...] libglew-dev, libglewmx-dev, [...] > > Why does it build-depend against both variants? > >> but libglewmx-dev 1.13.0-3 has >> >> Conflicts: libglew-dev > > The background here is that glew 2.0.0 removed MX support but things > like quesoglc and chromium-browser use the MX variant so I uploaded the > old version of glew as glewmx and dropped the non-MX variants of it. > > There are a few possibilities here: > > The k3d maintainer can try to figure out the reason for it using both > variants and switch to just one of them if possible. Yep, I will try to do that in the next few days. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#838516: FTBFS: conflicts between build dependencies
Hi Joachim, 2016-09-21 21:38 GMT+02:00 Joachim Reichel <reic...@debian.org>: > Source: k3d > Version: 0.8.0.5-4 > Severity: serious > > Hi, > > k3d 0.8.0.5-4 has > > Build-Depends: [...] libglew-dev, libglewmx-dev, [...] > > but libglewmx-dev 1.13.0-3 has > > Conflicts: libglew-dev > > (I want to rebuild k3d against the new cgal package which changed SONAMEs.) Thanks for the report and the analysis. I have to upload the new upstream release which fixes the glew 2 problems, will do it in the next few days. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#811866: More C++ help needed (Was: Bug#811866: fixed in hyphy 2.2.6+dfsg-4)
nge: _Formula f (*thisString,nil,false); to: _Formula f (*thisString,nil,nil); (or the more standard "nullptr", but since they already use 'nil', which I guess that it's an alias... I don't want to break their style). /build/hyphy-2.2.6+dfsg/src/core/include/formula.h:87:5: note: no known conversion for argument 3 from 'bool' to '_String*' /build/hyphy-2.2.6+dfsg/src/core/include/formula.h:86:5: note: candidate: _Formula::_Formula() _Formula (void); ^~~~ /build/hyphy-2.2.6+dfsg/src/core/include/formula.h:86:5: note: candidate expects 0 arguments, 3 provided /build/hyphy-2.2.6+dfsg/src/core/include/formula.h:79:9: note: candidate: _Formula::_Formula(const _Formula&) class _Formula // a computational formula ^~~~ /build/hyphy-2.2.6+dfsg/src/core/include/formula.h:79:9: note: candidate expects 1 argument, 3 provided /build/hyphy-2.2.6+dfsg/src/gui/HYChartWindow.cpp: In member function 'virtual void _HYDistributionChartWindow::AddVariable(_String*)': /build/hyphy-2.2.6+dfsg/src/gui/HYChartWindow.cpp:4530:45: error: no matching function for call to '_Formula::_Formula(_String&, NULL, bool)' These don't seem a good candidate in this case. In any event, it's probably upstream who should take a look at this, because changing the code without knowing exactly what it does is never a good idea :-) Hope that helps! -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#834204: libsdl1.2: Nonfree file: src/video/fbcon/riva_mmio.h
Hi, 2016-08-13 3:44 GMT+01:00 Legimet <legimet.c...@gmail.com>: > Source: libsdl1.2 > Version: 1.2.15+dfsg1-4 > Severity: serious > Justification: Policy 2.1 > > Dear Maintainer, > > The file src/video/fbcon/riva_mmio.h has a nonfree license that does not > explicitly allow modification. Thanks for the report. I am copying FTP-masters to know their opinion. This file has been present in Debian for the best part of 2 decades, so possibly the people who reviewed and approved this initially are not around anymore or, if they are, that they don't recall the details if they were discussed. >From my understanding, despite the brevity of the wording but given the context, with "using this code in individual and commercial software" is implicit the possibility of modification, as in "use in any way you wish" -- modifications might be needed due to changes in compiler/toolchain or to integrate in the bigger "commercial" software (e.g. changing names to avoid clashes). These licenses are usually to prevent that the source code is leaked/accessible to the outside world, or used in commercial software without being paid. Since this license prevents neither, I don't think that prevent modification is of any use to the copyright holders... but it's true that it doesn't explicitly allow modification or says anything beyond "use". > The file is from xf86-video-nv, and has > subsequently been relicensed under the MIT/Expat license: > https://cgit.freedesktop.org/xorg/driver/xf86-video-nv/tree/src/riva_hw.h > > It should be possible to use the newer version of the file. The code is not identical, for example the "NV_" macros in the beginning of the old file are not present in the second. The "struct _riva_hw_inst" is different in both versions as well (e.g. fields Architecture and Version present in the first file, but not in the second), so not API nor ABI compatible. So it needs to be handled with some care in any case. (BTW, it would be nice to discuss this with upstream if it needs to be removed/updated, unfortunately I don't have much time in the next few weeks, so if somebody beats me to it I will not complain :) . They should also have access to some nice legal department, being developed by Steam now). Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#825471: libunistring0: soname change without package name change
2016-05-27 9:02 GMT+01:00 Stephen Kitt <sk...@debian.org>: > On Fri, May 27, 2016 at 07:15:48AM +0200, Andreas Metzler wrote: >> 0.9.6-1.1 features a soname bump from libunistring.so.0 to >> libunistring.so.2, without changing the package name and making a >> library transition. This breaks all reverse dependencies, e.g.: > > I'm preparing an NMU to revert to 0.9.3 (so the version will end up > being 0.9.6+really0.9.3 since I need to re-upload an orig tarball). Oh dear, sorry for the mess :( I can work on that if needed, but if you are ready please go ahead. > Manuel, if you want to re-do the transition, you can simply use > version 0.9.6+really0.9.6, until 0.9.7 is released. Yes, I'll look into it once the main problem is addressed. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#805852: ipe: diff for NMU version 7.1.10-1.2
Hi Laurent, 2016-05-02 16:22 Laurent Bigonville: Control: tags 805852 + pending Dear maintainer, I've prepared an NMU for ipe (versioned as 7.1.10-1.2) and uploaded it to DELAYED/5. Please feel free to tell me if I should delay it longer. Thanks a lot for this. I just noticed that it affects one of my packages so I was about to NMU it myself, and came here only to see that you saved me from it. So just wanted to say that -- Thanks! -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#814276: Non-Free file: src/stdlib/SDL_qsort.c
[Update] The issue has been fixed in the libsdl1.2 package (#814445), but copying this last bit of info in the case that it's useful for the future, in the case that we need to revisit the issue later. 2016-02-21 13:04 Ben Hutchings: Gareth has now updated the licence text at <http://www.mccaughan.org.uk/g/software.html#qsort> So Ben Hutchings contacted the author of the original code and the author promptly relicensed and clarified some aspects, so this doesn't seem to be a legal threat. In the meanwhile, we had notified SDL upstream and they had changed the implementation for another one, and when Gareth relicensed it they added back the new version of Gareth's qsort, so it will be present in the next releases: https://hg.libsdl.org/SDL/log/9cec5fe32bca/src/stdlib/SDL_qsort.c I tried to backport the fix but there are some technical problems to get this to work, it doesn't seem to compile right away, not even after several hacks. I'd rather wait for the next upstream release to happen rather than to keep spending time on this, now that things are clarified and that it seems largely a theoretical threat. Hopefully the next upstream release will arrive soon, but maybe the autoremoval process from testing will kick-in in between, and also I am not sure if it's a good idea to reduce the severity of this bug. This code has been there since forever with the same license for many many Debian releases, and as explained it doesn't seem to be a legal threat, but still. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#816080: [wajig] Segfault on wajig show command for some packages.
2016-03-02 5:43 GMT+00:00 Paweł Różański <ro...@poczta.onet.pl>: >>>> Does the crash happen only for the "not installed" packages and it's >>>> fine for the "installed" ones? If so, it's #815581, fix to be released >>>> tomorrow or so. >>> >>> So I'm going to assume that this is the case and will merge the reports >>> now. >> >> Didn't test throughly, as I waited for new version, but quick check >> confirms, that bug indeed appears only for not installed packages. > > Just upgraded aptitude to 0.7.7-1. Both aptitude and wajig work fine, so > solved. :-) > > Thank you! That's good, thanks for the confirmation! -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#815978: aptitude: 'aptitude show' segfaults on some packages
2016-02-26 11:10 anabioz34: Can you please confirm that for example unattended-upgrades was not installed in your system? Yes, it's not installed in my system. OK, thanks! -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#814276: Non-Free file: src/stdlib/SDL_qsort.c
Hi Ben, 2016-02-21 03:09 Ben Hutchings: I happen to know the original author, so I've mailed him requesting he consider relicencing. I suppose that you were looking into this as part of the BSP. I notified upstream a few days ago, and they didn't want to be in possible breach of the license, so they changed the implementation for libsdl2: http://lists.alioth.debian.org/pipermail/pkg-sdl-maintainers/2016-February/002374.html libsdl1.2 suffers from the same problem, but we can just repack the orig.tar and disable the use of this implementation (it's supposed to not be used by default, so an empty file would do, or otherwise the file from libsdl2 can be used). So, in summary, I am going to upload fixes in the next few days. At this point I suspect that upstream is not going to go back (unless the implementation that they now use is problematic). Maybe it's good if you could get this relicenced just in case, e.g. for the benefit of other distros. What do you think? Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#814276: Non-Free file: src/stdlib/SDL_qsort.c
Control: tags -1 + upstream Control: clone -1 -2 Control: reassign -2 src:libsdl1.2 Hi, 2016-02-09 20:45 stresswa...@ruggedinbox.com: Package: libsdl2 Version: 2.0.2+dfsg1-6 Severity: serious The file 'src/stdlib/SDL_qsort.c' in SDL2 seems to disallow modification. Thanks for the report. This also affects v1.2, this file has been there since forever, so I am cloning the bug report there. We're in contact with upstream to try to solve the problem, since it also affects them. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#814408: aptitude uses all disk space (12G) with recursive trace-dump in /tmp
Control: severity -1 minor Hi, 2016-02-11 10:00 Chris Tillman: Package: aptitude Version: 0.7.5-3 Severity: critical Justification: breaks unrelated software This is not a critical bug by any strectch, anymore than wget or any browser might break unrelated software if you download a partition without enough space (when other packages depend on empty space in that partition to work fine). Many packages use /tmp and can cause this problem under various circumstances, even with much smaller files. Simply downloading files in aptitude for an upgrade can fill up /var/cache/apt/archives, which might mean / and /tmp if it's a single partition, and aptitude never stopped to be released because of that behaviour. There is a simple workaround for that, I suspect, which is to use the defaults and not enable options related with trace-dumps. It would be useful though if you could mention the exact config or command line options that you enabled to make this happen. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#810066: libogre-1.8.0: not installable in sid
Hi Ralf, 2016-01-06 8:31 GMT+00:00 Ralf Treinen <trei...@free.fr>: > Package: libogre-1.8.0 > Version: 1.8.0+dfsg1-7 > Severity: serious > User: trei...@debian.org > Usertags: edos-uninstallable > > Hi, > > libogre-1.8.0 is not installable in sid on any architecture. This is the > case since 2015-08-02. > > The reason is that libogre-1.8.0 depends on libstdc++6. However, > libstdc++6 (5.3.1-5) declares a Breaks relation with > libogre-1.8.0 (<= 1.8.0+dfsg1-7+b1). There's a request to FTP masters to remove this package since the last release, so please disregard this package. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#809130: ogre-1.8: FTBFS: "The following REQUIRED packages could NOT be located on your system: freetype"
Hi Chris, 2015-12-27 13:10 GMT+00:00 Chris Lamb <la...@debian.org>: > Source: ogre-1.8 > Version: 1.8.0+dfsg1-7 > Severity: serious > Justification: fails to build from source > User: reproducible-bui...@lists.alioth.debian.org > Usertags: ftbfs > X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org > > Dear Maintainer, > > ogre-1.8 fails to build from source in unstable/amd64: The package is set to be RMed by FTP-masters for a few months already. There are some problems with rdeps which haven't been updated/built in years, but in principle you can forget about ogre-1.8 for the purpose of reproducible builds. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#803300: prepare for giflib5
Hi all, 2015-12-13 15:33 GMT+00:00 Sebastiaan Couwenberg <sebas...@xs4all.nl>: > 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.1-7ubuntu3.diff.gz > > Upstream has fixed the giflib5 support a bit differently [0][1]. > > The attached debdiff uses the upstream changes for giflib 5.x instead of > those applied in Ubuntu. > > Please include these changes in openscenegraph (3.2.1-9) to prevent > testing autoremoval of openscenegraph and all its reverse dependencies > because of this RC bug. > > [0] > https://github.com/openscenegraph/osg/commit/afb442fccd182cfe8608f43394af016f6723f97a > [1] > https://github.com/openscenegraph/osg/commit/18213bfb67d464715af618fd8c73549f749625b9 Thanks both. I can work on this towards the end of next week (17-20th or so), not before. I don't know if Alberto will be able to upload before then. There are a few other pending things to fix, so I think that it would be better that either Alberto or I get around to work on this and fix the issues in a single upload, so the less powerfull arches are not taxed too much. The removal from testing will happen in a month, so there should be plenty of time. But if for some reason we do not upload in ~10 days and you want to finish the transition, and the NMU includes the mentioned patches, it's OK for me (I suppose that also for Alberto, if he doesn't reply). Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#802958: aptitude: artificial report to prevent migrating the package to testing
Package: aptitude Version: 0.7.4-1 Severity: serious 0.7.4 will migrate to testing soon, so this is a way to hold the migration. It is not very elegant and it would be nice to have another way to achieve this other than with changes in BTS, but I don't think that there are any. The reason for holding the migration is because I think that 0.7.2 currently in testing is more "stable" than the new ones, and it's better to give more time of exposure in unstable to the changes in .3 and .4, some of which have profound implications, and the fixes or new features are nice to have but not urgent. -- Manuel
Bug#801430: aptitude: segfault maybe casued by package dependency loop aptitudeDepCache::internal_mark_delete loop here
2015-10-20 18:44 GMT+01:00 Nick Black <nick.bl...@sprezzatech.com>: > I can confirm that 0.7.4 fixes the issue I reported. Good work. Good, thanks for the confirmation! -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#802170: libopenscenegraph100v5: Can't install; package depends on libgdal.so.1-1.11.2 which doesn't exist
Control: severity -1 important Control: tags -1 + moreinfo unreproducible 2015-10-18 1:36 GMT+01:00 John Haiducek <jhaid...@gmail.com>: > Package: libopenscenegraph100v5 > Version: Package depends on libgdal.so.1-1.11.2 which isn't provided by any > package > Severity: serious > Justification: 2 > > Dear Maintainer, > > *** Reporter, please consider answering these questions, where appropriate *** > >* What led up to the situation? > > I tried to install flightgear > >* What exactly did you do (or not do) that was effective (or > ineffective)? > > apt-get install flightgear > apt-get install libopenscenegraph100v5 > >* What was the outcome of this action? > > The following packages have unmet dependencies: > flightgear : Depends: libopenscenegraph100v5 but it is not going to be > installed > Depends: libsimgearscene3.4.0 (>= 3.4.0~) but it is not going to > be installed > > The following packages have unmet dependencies: > libopenscenegraph100v5 : Depends: libgdal.so.1-1.11.2 > >* What outcome did you expect instead? > > libopenscenegraph100v5 should install along with its dependencies With an up-to-date unstable, "apt install openscenegraph" installs fine. Maybe some of the dependencies cannot be installed in testing due to transitions or other reasons. That library libgdal.so.1-1.11.2 is provided by libgdal1i, you can try "apt-get install libgdal1i" to see if there are further explanations why that package cannot be installed in your system. We do no add the dependency of libgdal.so.1-1.11.2 directly, it was added by depending on libgdal-dev. I think that if there are any problems with this is due to changes in that package or knock-on effects. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#801430: aptitude: segfault maybe casued by package dependency loop aptitudeDepCache::internal_mark_delete loop here
Control: tags -1 + pending
2015-10-13 1:06 GMT+01:00 Nick Black <nick.bl...@sprezzatech.com>:
> if you want me to pull something and test it, i ought be able to within a
> day or so.
OK, if you can confirm it would be great, thanks.
Other than that, I already commited it to git, because I am pretty
confident that this is the issue behind it, so marking as +pending.
Cheers.
--
Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
From d6b67aba318ab83752f10adabf1b0490d2c88b39 Mon Sep 17 00:00:00 2001
From: "Manuel A. Fernandez Montecelo" <manuel.montez...@gmail.com>
Date: Wed, 14 Oct 2015 23:53:44 +0100
Subject: [PATCH 1/2] Fix for circular dependencies in internal_mark_delete()
(Closes: #801430)
Under some circumstances, when following reverse dependencies of packages to
be deleted to see if they are automatically installed and unused (so they
can be pro-actively marked for deletion as well), the function calls itself
recursively. In this case, it uses this version with an extra parameter to
detect when packages were already visited, to avoid infinite loops in the
case of circular dependencies (bug #801430).
---
NEWS| 9 +
src/generic/apt/aptcache.cc | 28 ++--
src/generic/apt/aptcache.h | 15 +++
3 files changed, 50 insertions(+), 2 deletions(-)
diff --git a/NEWS b/NEWS
index c8f49b1..7187b05 100644
--- a/NEWS
+++ b/NEWS
@@ -19,6 +19,15 @@ Version 0.7.4 UNRELEASED
errors, but didn't retrieve long descriptions anymore (it did for short
ones).
+ * Fix for circular dependencies in internal_mark_delete() (Closes: #801430)
+
+Under some circumstances, when following reverse dependencies of packages to
+be deleted to see if they are automatically installed and unused (so they
+can be pro-actively marked for deletion as well), the function calls itself
+recursively. In this case, it uses this version with an extra parameter to
+detect when packages were already visited, to avoid infinite loops in the
+case of circular dependencies (bug #801430).
+
- User visible changes:
* [cmdline] In versioned provides, include '=' symbol (Closes: #767393)
diff --git a/src/generic/apt/aptcache.cc b/src/generic/apt/aptcache.cc
index 838c1da..7cec034 100644
--- a/src/generic/apt/aptcache.cc
+++ b/src/generic/apt/aptcache.cc
@@ -1231,6 +1231,15 @@ void aptitudeDepCache::internal_mark_delete(const PkgIterator ,
bool Purge,
bool unused_delete)
{
+ std::vector unused_already_visited;
+ internal_mark_delete(Pkg, Purge, unused_delete, unused_already_visited);
+}
+
+void aptitudeDepCache::internal_mark_delete(const PkgIterator ,
+ bool Purge,
+ bool unused_delete,
+ std::vector& unused_already_visited)
+{
// honour ::Purge-Unused in the main entry point for removing packages, it
// should catch cases of automatically installed and unused packages not
// purged (#724034 and others)
@@ -1275,6 +1284,21 @@ void aptitudeDepCache::internal_mark_delete(const PkgIterator ,
if (Pkg.CurrentVer().end())
return;
+ // to avoid endless recursion/crashes, check if this package has already been
+ // visited for this purpose (the container has to be empty at the start of
+ // each run)
+ auto it = std::find(unused_already_visited.begin(), unused_already_visited.end(), Pkg->ID);
+ if (it == std::end(unused_already_visited))
+{
+ // not previously visited, register
+ unused_already_visited.push_back(Pkg->ID);
+}
+ else
+{
+ // already visited
+ return;
+}
+
// from now and for the remaining of this function, these are "unused
// deletes", so set variable accordingly
unused_delete = true;
@@ -1326,7 +1350,7 @@ void aptitudeDepCache::internal_mark_delete(const PkgIterator ,
// if we reach here, can delete the real package providing the
// dependency
- internal_mark_delete(dep_prv.OwnerPkg(), Purge, unused_delete);
+ internal_mark_delete(dep_prv.OwnerPkg(), Purge, unused_delete, unused_already_visited);
}
// it was a virtual package -- so stop processing the considered
@@ -1356,7 +1380,7 @@ void aptitudeDepCache::internal_mark_delete(const PkgIterator ,
continue;
}
- internal_mark_delete(dep_pkg, Purge, unused_delete);
+ internal_mark_delete(dep_pkg, Purge, unused_delete, unused_already_visited);
}
}
}
diff --git a/src/generic/apt/aptcache.h b/src/generic/apt/aptcache.h
index 51a0990..a7d716c 100644
--- a/src/generic/apt/aptcache.h
+++ b/src/generic/apt/aptcache.h
@@ -330,7 +330,22 @@ private:
* package's auto flag is set properly.
*/
void internal_mark_install(const PkgIterator , bool AutoInst, bool ReInstall);
+
+ /** Internally marking packages for deletion -- main entry point
+ */
void internal_mark_delete(const PkgIterator , bool Purge, bool unused_delete);
+ /**
Bug#801430: aptitude: segfault maybe casued by package dependency loop aptitudeDepCache::internal_mark_delete loop here
2015-10-12 22:35 GMT+01:00 Nick Black <nick.bl...@sprezzatech.com>: > As a datum (I reported a duplicate of this bug as 801488), I removed both > libxmlrpc-lite-perl and libsoap-lite-perl, and still see the crash. So I > don't think they're to blame, as asserted earlier on this bug. They also > would seem unlikely causes for the gdb/valgrind output I reported in that > bug. I tried to replicate it and I could not yet with the different scenarios in these bug reports. I think that I have a fix for this, but since I couldn't test it I am not 100% sure and I am waiting -- but hopefully it will be fixed soon and will appear in the next release after that. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#795814: FTBFS: boost/math/tools/test.hpp: No such file or directory
2015-09-03 22:27 GMT+01:00 Jonathan Wiltshire <j...@debian.org>: > On Mon, Aug 24, 2015 at 09:30:25AM +0100, Manuel A. Fernandez Montecelo wrote: >> So it will need a bit more investigation and possibly to speak with >> upstream about it -- I think that the fix will need a few days (at >> least) to arrive. > > As there is no prospect of a fix for now and k3d is causing a blockage on > several interrelated transitions, I have temporarily removed it from > testing. Goody, thanks. I had already told jcristau on IRC to do so if it caused problems. I don't know when I will be able to find a solution, so good that you removed the +pending. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#795814: FTBFS: boost/math/tools/test.hpp: No such file or directory
2015-08-23 23:50 GMT+01:00 Simon McVittie s...@debian.org: On Mon, 17 Aug 2015 at 09:57:16 +0100, Manuel A. Fernandez Montecelo wrote: Today it cannot even start to compile because of conflics of deps to install: The following packages have unmet dependencies: libopenexr6v5 : Conflicts: libopenexr6 but 1.6.1-8 is to be installed. libilmbase6v5 : Conflicts: libilmbase6 but 1.0.1-6.1 is to be installed. libcairomm-1.0-1v5 : Conflicts: libcairomm-1.0-1 but 1.10.0-1.1+b1 is to be installed. I think this was caused by a mis-build of imagemagick on amd64[1] which has now been fixed by a binNMU. Please try again; I can reproduce the original build failure in sbuild today. I think this might be the last sourceful upload needed by the imagemagick sub-transition within the larger libstdc++ mess. S [1] The mirror used by my sbuild chroot hadn't seen libopenexr6v5 yet, causing it to be built against libopenexr6 on amd64 only. I for one welcome our new throw away maintainer-built binaries overlords. Thanks for the update. I get this error now at 98% (and there seem to be a non-fatal error before): ERROR: Plugin doesn't implement interface: Python ERROR: /tmp/buildd/k3d-0.8.0.3/k3dsdk/scripting.cpp line 55: assertion `engine' failed ERROR: Error executing script [ /tmp/buildd/k3d-0.8.0.3/obj-x86_64-linux-gnu/share/k3d/guide/content/plugins.py ] So it will need a bit more investigation and possibly to speak with upstream about it -- I think that the fix will need a few days (at least) to arrive. Cheers. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com
Bug#795814: FTBFS: boost/math/tools/test.hpp: No such file or directory
Control: tags -1 + pending 2015-08-17 8:34 GMT+01:00 Simon McVittie s...@debian.org: Source: k3d Version: 0.8.0.3-7 Severity: serious Justification: fails to build from source (but built successfully in the past) When rebuilt for libsigc++-2.0-0v5, k3d fails to build from source https://buildd.debian.org/status/package.php?p=k3d: In file included from /«PKGBUILDDIR»/k3dsdk/inode.h:28:0, from /«PKGBUILDDIR»/k3dsdk/data.h:28, from /«PKGBUILDDIR»/k3dsdk/plugins_detail.h:27, from /«PKGBUILDDIR»/k3dsdk/plugin.h:27, from /«PKGBUILDDIR»/k3dsdk/application_detail.cpp:25: /«PKGBUILDDIR»/k3dsdk/difference.h:34:37: fatal error: boost/math/tools/test.hpp: No such file or directory I suspect this is a result of the update from Boost 1.55 to Boost 1.58. Thanks for taking a look. Yes, it is a problem due the changes in boost, and I have a fix for this but it didn't compile in a clean pbuilder when I tried ~5 days ago, because of dependencies not being ready: /tmp/buildd/k3d-0.8.0.3/modules/imagemagick_io/bitmap_importer.cpp:62: undefined reference to `Magick::Image::read(std::__cxx11::basic_stringchar, std::char_traitschar, std::allocatorchar const)' collect2: error: ld returned 1 exit status Today it cannot even start to compile because of conflics of deps to install: The following packages have unmet dependencies: libopenexr6v5 : Conflicts: libopenexr6 but 1.6.1-8 is to be installed. libilmbase6v5 : Conflicts: libilmbase6 but 1.0.1-6.1 is to be installed. libcairomm-1.0-1v5 : Conflicts: libcairomm-1.0-1 but 1.10.0-1.1+b1 is to be installed. I'm keeping an eye on this, and I will fix it as soon as it is possible to do it. Cheers. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com
Bug#790991: cal3d: library transition may be needed when GCC 5 is the default
Uploaded changes to experimental. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com
Bug#791165: libsdl-sge: library transition may be needed when GCC 5 is the default
2015-08-01 22:36 GMT+01:00 Matthias Klose d...@debian.org: reopen 791165 severity 791165 serious tags 791165 + confirmed retitle 791165 libsdl-sge: library transition is needed when GCC 5 is the default thanks this is exactly what you should *not* do: libsdl-sge (030809dfsg-5) unstable; urgency=medium . * Bump Policy Standars-Version to 3.9.6 (no changes needed) * Rebuild against GCC-5 (Closes: #791165) * Enable parallel compilation with dh * Fix mispelling in d/copyright (detected by lintian) Please rename the library package (and add a proper library version). Why not? I already explained in the bug report why IMO we don't need a transition: - no packages in Debian use the functions In addition: - supertransball2 is going to be NMUd in the libstdc++ transition anyway - ruby-sdl has 200 reported installations in popcon, supertransball 129, infon-viewer 20 (the risk of breakage is not high, and it's in very unimportant packages) - it looks to me that RT are not very happy with unnecessary / gratuitous transitions [1], which to me it reads as if they can avoid them unless really needed [1] https://lists.debian.org/debian-release/2015/07/msg00333.html Cheers. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#777778: [Aptitude-devel] Bug#792681: cwidget ftbfs with GCC 5
2015-07-20 15:24 GMT+01:00 Matthias Klose d...@debian.org: On 07/18/2015 11:29 PM, Manuel A. Fernandez Montecelo wrote: Anyway, aptitude with GCC-5 and -std=c++98 also suffers the same problem as cwidget, because it fails to compile the cwidget header, if nothing else. But if cwidget goes C++11, it forces aptitude to go C++11, and it doesn't work for other reasons (that I am working to fix), so we are between a rock and a hard place. Even if I can fix things in time before the deadline, maybe subtle changes like the ABI problems make aptitude fail in catastrophic ways, there is not much time to expose it and be tested before the deadline in experimental or similar. I am thinking that the best solution is to force them to stay with gcc-4.9 for the time being, it looks the safest bet. After that or in parallel, as soon as I get things working, I can upload to experimental the changes that allow them to work with C++11, and keep it there for a while before moving to unstable. no, this is definitely *not* an option. cwidget and aptitude b-d on libsigc++-2, and this will be built using GCC 5. There will be neither g++-4.9 nor g++-4.8 in the archive once we finish this transition. Maintainers don't have the choice to fall-back to an older version this time. Right. So I have been working through the weekend to get aptitude to compile with -std=c++11 (working in my system but still not pushed). As you reported, there are problems compiling aptitude with gcc-5 in the default mode, and after the failure that you reported it will stumble upon the same problem that cwidget when including that cwidget header (for which passing -std=c++11 is the simplest solution, and also the only that I found so far). In terms of C++-based dependencies, aptitude depends on libsigc++-2.0, xapian-core (#791312, it will not be ready immediately but soon enough, it seems), apt and boost (gcc-5 ready, it seems). I don't know the details about sigc++ and apt, but if all of them are going to be compiled with gcc-5 soon after its move to unstable, cwidget and aptitude will be ready as well. Now we have to work out the details about how to upload the changes, enable them in lockstep and avoid breakages as much as possible (e.g. tighten versions on the compiler and lib dependencies). Cheers. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#777778: [Aptitude-devel] Bug#792681: cwidget ftbfs with GCC 5
2015-07-18 09:50 Matthias Klose: On 07/17/2015 06:57 PM, Manuel A. Fernandez Montecelo wrote: Hello, 2015-07-17 14:13 GMT+01:00 Matthias Klose d...@debian.org: Package: src:cwidget Version: 0.5.17-2 Severity: normal Tags: sid stretch patch User: debian-...@lists.debian.org Usertags: ftbfs-gcc-5 GCC 5 complains about using c++11 features without passing -std=c++11. Also setting the maintainer flag without exporting it doesn't help. patch at https://launchpadlibrarian.net/211899860/cwidget_0.5.17-2ubuntu1_0.5.17-2ubuntu2.diff.gz If I found the correct build log where you determined this [1], the compiler fails when including In file included from /usr/include/c++/5/string:52:0, from ../../../src/cwidget/curses++.h:25, from colors.cc:22: Line 22 of colors is: #include cwidget/curses++.h And line 25 of curses++.h is: #include string The error is: --- /usr/include/c++/5/bits/basic_string.h: In instantiation of 'union std::__cxx11::basic_stringcwidget::wchtype::anonymous': /usr/include/c++/5/bits/basic_string.h:119:7: required from 'class std::__cxx11::basic_stringcwidget::wchtype' ../../../src/cwidget/curses++.h:199:31: required from here /usr/include/c++/5/bits/basic_string.h:121:53: error: member 'cwidget::wchtype std::__cxx11::basic_stringcwidget::wchtype::anonymous union::_M_local_buf [1]' with constructor not allowed in union _CharT _M_local_buf[_S_local_capacity + 1]; ^ /usr/include/c++/5/bits/basic_string.h:121:53: note: unrestricted unions only available with -std=c++11 or -std=gnu++11 --- This is because wchtype does not seem to be able to be used as part of unions inside basic_string.h because the constructors/destructors are not trivial enough. I was trying to work around this for a while, because I think that forcing c++11 mode will have cascading effects on rev-deps (currently only one within Debian, but it is aptitude with almost 100% of reported installations by popcon), but I could not find a satisfactory solution yet. Is there a deadline to fix this? yes, Jul 31. please see my email to d-d-a. OK. I knew of the deadline to set GCC-5 as default, I was asking in the case that you planned to NMU before that or not even after it was made default. [1] https://people.debian.org/~doko/logs/gcc5-20150701-ftbfs/logs-failed-gcc5/cwidget_0.5.17-2_unstable_gcc5.log this was the error I saw: [...] Making all in config make[5]: Entering directory '/scratch/packages/tmp/cwidget-0.5.17/src/cwidget/config' /bin/bash ../../../libtool --tag=CXX --mode=compile g++ -DLOCALEDIR=\/usr/share/locale\ -DHAVE_CONFIG_H -I. -I../../.. -Wall -Werror -I../../.. -I. -I../../.. -I../../../src -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_REENTRANT -I/usr/include/sigc++-2.0 -I/usr/lib/x86_64-linux-gnu/sigc++-2.0/include -c -o colors.lo colors.cc libtool: compile: g++ -DLOCALEDIR=\/usr/share/locale\ -DHAVE_CONFIG_H -I. -I../../.. -Wall -Werror -I../../.. -I. -I../../.. -I../../../src -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_REENTRANT -I/usr/include/sigc++-2.0 -I/usr/lib/x86_64-linux-gnu/sigc++-2.0/include -c colors.cc -fPIC -DPIC -o .libs/colors.o In file included from /usr/include/c++/5/string:52:0, from ../../../src/cwidget/curses++.h:25, from colors.cc:22: /usr/include/c++/5/bits/basic_string.h: In instantiation of 'union std::__cxx11::basic_stringcwidget::wchtype::anonymous': /usr/include/c++/5/bits/basic_string.h:119:7: required from 'class std::__cxx11::basic_stringcwidget::wchtype' ../../../src/cwidget/curses++.h:199:31: required from here /usr/include/c++/5/bits/basic_string.h:121:53: error: member 'cwidget::wchtype std::__cxx11::basic_stringcwidget::wchtype::anonymous union::_M_local_buf [1]' with constructor not allowed in union _CharT _M_local_buf[_S_local_capacity + 1]; ^ /usr/include/c++/5/bits/basic_string.h:121:53: note: unrestricted unions only available with -std=c++11 or -std=gnu++11 Makefile:448: recipe for target 'colors.lo' failed make[5]: *** [colors.lo] Error 1 make[5]: Leaving directory '/scratch/packages/tmp/cwidget-0.5.17/src/cwidget/config' Makefile:603: recipe for target 'all-recursive' failed make[4]: *** [all-recursive] Error 1 I get this error with GCC-5 even if I let the default or explicitly set -std=c++98, which is strange -- why does it try to include C++11 stuff even then, like the namespaces in required from 'class std::__cxx11::basic_stringcwidget::wchtype' in the errors above? It's a bit odd. Also, this code did not change for many years and it was compiling fine, I was trying to look at GCC changelog but I did not see anything immediately obvious that it causes it to fail after years working fine. Anyway, aptitude with GCC-5
Bug#732725: We intent to request the removal of libogre-perl (was: Re: Bug#732725: libogre-perl: Please upgrade OGRE dependency to 1.9 when upstream ready)
2015-05-23 15:48 GMT+01:00 Axel Beckert a...@debian.org: Hi, the Debian Perl Team intents to file a removal bug for libogre-perl as * it no more builds against libogre 1.9 (#732725); * its upstream seems inactive since 2013, see https://rt.cpan.org/Public/Bug/Display.html?id=94066#txn-1344923; * it never had much popcon (maximum 26, current 22, vote maximum 7, vote current 1); and * it has no hard reverse dependencies. The only non-hard reverse dependencies are * games-perl-dev which Recommends it, and * libois-perl which Enhances it. Unless there are objections _and_ a fix, we'll soon file a removal bug report for libogre-perl soon. Cc to the submitter of #732725, the games-perl-dev maintainers and Dmitry E. Oboukhov who RFP'ed libogre-perl. (The maintainer of libois-perl is the Debian Perl Team itself, hence I'll remove that Enhances header there myself, soon, too.) Thanks for the update, Axel. Perhaps we could make an effort to get it to compile with ogre-1.9, but even this version is oldish and I expect that we will have soon 1.10 and 2.x, most probably requiring even more changes to rev-depends. The lack of upstream development is indeed a concern, and the popcon usage is low (I wonder if anybody is indeed developing with libogre-perl), so I think that it's probably not very worth to try to keep it alive for another release cycle. OIS is not completely OGRE-dependent, but I guess that most of the projects using it come from the OGRE world -- OIS was once part of OGRE. That said, if it works, no reason to remove it. Cheers. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#784181: razorqt: Razor-Qt dead upstream, superseded by LXDE-Qt
Source: razorqt Version: 0.5.2-4 Severity: serious Tags: upstream The project has merged with LXDE to form LXDE-Qt, and new packages from the new effort will pop up soon in Debian, so Razor-Qt should not be present in the next releases, thus submitting this bug report to get it removed from testing. Furthermore, with the plans from KDE/Qt teams to move away from Qt4, this package will start to fail to build from source soon. I plan to ask FTP-masters for removal from unstable in a few months, when the new desktop is usable. More info: http://sourceforge.net/p/lxde/mailman/message/31196887/ http://blog.lxde.org/?p=1046 -- Manuel -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760058: Will Ogre 1.8 remain in Jessie? (Was: The other packages)
2015-04-29 4:10 GMT+01:00 Olek olek_nos...@suddenlinkmail.com: On 04/27/2015 05:41 PM, Manuel A. Fernandez Montecelo wrote: 2014-10-25 15:05 GMT+01:00 Manuel A. Fernandez Montecelo manuel.montez...@gmail.com: 2014-10-25 12:21 Olek: Does anyone know if Ogre 1.8 will actually be removed from testing? If so, something needs to be done with ember. I do not plan to actively ask to remove it at this point, but it is not possible to reply to your question with all certainty. [...] Raising the severity to serious now. In the end it was shipped in Jessie, but I will ask this old OGRE version to be removed from unstable soon, at which point this package will fail to build from source. Thanks for the update! Unfortunately, life has been quite busy here. I'm hoping to resume my prior packaging rhythm soon but it might be another month or so. Difficult to tell at the moment. I know Stephen is pretty busy as well. If he doesn't have time to get to this then I'll look at it as soon as I'm able to. There is no immediate rush to do that, but I don't want to leave it for very long. Perhaps in the meantime I will submit a RC bug to it so it does not get included in testing/next-stable, ember will be auto-removed from testing, but that's it. Anyway, the worst that can happen if ember is not upgraded in months is that if I ask ogre-1.8 to be removed from unstable and FTP masters agree while having reverse-dependencies still in unstable, the ember package will FTBFS for a while, and eventually if this is not fixed, it would be removed. Even then, ember can be reintroduced in the archive at any point after that. Since the package has to be upgraded to a new upstream version, it will have to go through the FTP NEW queue anyway, which is the most slow/annoying part. So this was a heads-up to tell you about my plans so you can plan accordingly, but there's no need to rush or get too stressed even if things get to the worse possible scenario :-) Cheers. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773059: ogre-doc: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE
2014-12-13 20:08 GMT+00:00 Andreas Beckmann a...@debian.org: Package: ogre-doc Version: 1.7.4+dfsg1-7 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Control: affects -1 + ogre-doc-nonfree Hi, an upgrade test with piuparts revealed that your package installs files over existing symlinks and possibly overwrites files owned by other packages. This usually means an old version of the package shipped a symlink but that was later replaced by a real (and non-empty) directory. This kind of overwriting another package's files cannot be detected by dpkg. This was observed on the following upgrade paths: lenny (ogre-doc-nonfree) - squeeze - wheezy - jessie Hi Andreas, ogre-doc-nonfree was removed from unstable in mid 2010 due to ROM; superceded by ogre 1.6.4.dfsg1-1, and 1.6.4.dfsg1-1 was uploaded in October 2009, and was the version shipped with squeeze (oldstable, at this moment), released in Feb 2011. ogre-doc-nonfree did not even ship in squeeze. On the other hand, ogre-doc is not going to be released in Jessie (removed from testing and unstable), so this would be only fixable with an upload to the next point release for wheezy. Lenny was first released in Feb 2009, last point release and security updates discontinued happened in Feb/March 2012. https://packages.qa.debian.org/o/ogre-doc-nonfree/news/20100610T185814Z.html https://packages.qa.debian.org/o/ogre/news/20091001T152940Z.html http://www.debian.org/releases/lenny/ I don't know if I understand this correctly, but it seems that when this breakage did happen was in the upgrade lenny-squeeze; and support for both of these distributions is discontinued already, right? Cheers. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770670: g++: fails to compile in c++0x mode on ppc64el with std::vector and SDL
2014-11-25 22:39 GMT+00:00 Manuel A. Fernandez Montecelo manuel.montez...@gmail.com: 2014-11-25 20:13 GMT+00:00 Dominique Dumont dominique.dum...@hp.com: [...] So, in summary, I don't think that this is serious (RC), and I even have doubts that it's important in a broad sense. I am quite sure that if you believe that it's important and explain it (we have a bug report of somebody affected, it's not purely theoretical!), they will let it to be applied -- but not 100%, I think that Release Managers are more reluctant to accept fixes than in previous releases. Good that it got accepted. Thanks for taking care of this :-) -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770670: g++: fails to compile in c++0x mode on ppc64el with std::vector and SDL
2014-11-25 20:13 GMT+00:00 Dominique Dumont dominique.dum...@hp.com: Hmm, according to [1], arm64 and ppc64el have made enough progress to be release architectures for Jessie. Britney no longer has special handling for these two. Therefore, FTBFS regressions for arm64 and ppc64el are now release critical (but non-regressions are not). Since the fix is quite easy, I think we should not bother the release team and upload the fixed package to unstable. (and we need to have the unblock approved by Dec 5th). Thoughts ? [1] https://lists.debian.org/debian-devel-announce/2014/11/msg5.html First and foremost, I am fine with whatever you want to do, I don't have a strong opinion. I gave my opinion in order to avoid (or at least be aware) the situation where we have a package in unstable during the freeze that release managers don't want to accept in testing. With ppc64el being fringe I meant that, independently of what the release team think, since this is not a mainstream architecture and quite recent, and the bug triggered only under certain conditions, I don't think that there will be lots of people affected by this bug. As a person who helped to get many key packages compiling on both these new architectures (and helped them in other various ways), and made changes to several SDL packages very early on (2013) to get these architectures supported, I am happy to get these things fixed and I do really care about these new ports. I am just pointing out that it's not libsdl2 itself which FTBFS while it compiled before (regression), in which case it would be RC for sure. It's only that some packages that use libsdl2, in C++ (not C or other languages), and (if I understood correctly) only when using the non-default and still experimental -std=c++0x, fail to compile. So, in summary, I don't think that this is serious (RC), and I even have doubts that it's important in a broad sense. I am quite sure that if you believe that it's important and explain it (we have a bug report of somebody affected, it's not purely theoretical!), they will let it to be applied -- but not 100%, I think that Release Managers are more reluctant to accept fixes than in previous releases. Cheers. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770670: g++: fails to compile in c++0x mode on ppc64el with std::vector and SDL
2014-11-24 7:28 GMT+00:00 Dominique Dumont d...@debian.org: libsdl2 rules file alerady has DEB_HOST_ARCH_CPU ?= $(shell dpkg-architecture -qDEB_HOST_ARCH_CPU) ifeq ($(DEB_HOST_ARCH_CPU),powerpc) confflags += --disable-altivec endif I'm going to tweak this file to use --disable-altivec on ppc64el arch. This should fix your problem. Just wondering... I am all for fixing this and the change seems easy enough, but would it be worth asking for pre-approval to the release team? If GCC-4.9 still does not officially claim to be fully C++11 compliant (which I don't think it does, but perhaps some later 4.9.x does -- in any case it's not switched on by default), and ppc64el being a new and somewhat fringe arch, and the bug does not affect to the availability of the package itself, I am not 100% sure if they will consider this RC. Cheers. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768213: gdb-doc: fails to upgrade from 'wheezy' - trying to overwrite /usr/share/man/man1/gdb.1.gz
2014-11-06 01:02 Andreas Beckmann:
Package: gdb-doc
Version: 7.7.1-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Hi,
during a test with piuparts I noticed your package fails to upgrade from
'wheezy'.
It installed fine in 'wheezy', then the upgrade to 'jessie' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.
See policy 7.6 at
http://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces
From the attached log (scroll to the bottom...):
Selecting previously unselected package gdb-doc.
Unpacking gdb-doc (from .../gdb-doc_7.7.1-1_all.deb) ...
dpkg: error processing /var/cache/apt/archives/gdb-doc_7.7.1-1_all.deb
(--unpack):
trying to overwrite '/usr/share/man/man1/gdb.1.gz', which is also in package
gdb-minimal 7.4.1+dfsg-0.1
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
Errors were encountered while processing:
/var/cache/apt/archives/gdb-doc_7.7.1-1_all.deb
cheers,
Andreas
Attaching patch with the agreement of Héctor, that he will apply later.
Cheers.
--
Manuel
diff --git a/debian/changelog b/debian/changelog
index 1de22dd..6b4c10b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,15 @@
+gdb-doc (7.7.1-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * d/control: Adding Breaks+Replaces of the binary package gdb-doc on
+gdb-minimal ( 7.7) as well as gdb and gdbserver, man pages were
+moved across packages. Thanks Andreas Beckmann for finding the
+problem (Closes: #768213)
+ * d/control: Add Vcs-* and Homepage fields
+ * d/control: Update Standards-Version to 3.9.6 (no changes required)
+
+ -- Manuel A. Fernandez Montecelo m...@debian.org Sun, 09 Nov 2014 10:05:02
+
+
gdb-doc (7.7.1-1) unstable; urgency=medium
* Imported Upstream version 7.7.1
diff --git a/debian/control b/debian/control
index f4210f7..f180349 100644
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,7 @@ Maintainer: Héctor Orón Martínez hector.o...@gmail.com
Uploaders: Samuel Bronson naes...@gmail.com
Section: non-free/devel
Priority: optional
-Standards-Version: 3.9.3
+Standards-Version: 3.9.6
Build-Depends: debhelper (= 7),
# These are just to satisfy the configure scripts ...
libtinfo-dev
@@ -15,13 +15,16 @@ Build-Depends-Indep:
texlive-fonts-recommended,
# ... and the Type1 fonts for ec from here
cm-super
+Vcs-Git: git://anonscm.debian.org/pkg-gdb/gdb-doc.git
+Vcs-Browser: http://anonscm.debian.org/gitweb/?p=pkg-gdb/gdb-doc.git
+Homepage: http://www.gnu.org/s/gdb/
Package: gdb-doc
Architecture: all
Section: non-free/doc
Depends: ${misc:Depends}
-Breaks: gdb ( 7.7), gdbserver ( 7.7)
-Replaces: gdb ( 7.7), gdbserver ( 7.7)
+Breaks: gdb ( 7.7), gdb-minimal ( 7.7), gdbserver ( 7.7)
+Replaces: gdb ( 7.7), gdb-minimal ( 7.7), gdbserver ( 7.7)
Description: The GNU Debugger Documentation
GDB is a source-level debugger, capable of breaking programs at
any specific line, displaying variable values, and determining
Bug#757106: missing license in debian/copyright
2014-08-05 12:41 GMT+01:00 Thorsten Alteholz alteh...@debian.org: Package: openscenegraph Version: 3.2.1-1 Severity: serious User: alteh...@debian.org Usertags: ftp X-Debbugs-CC: ftpmas...@ftp-master.debian.org thanks Dear Maintainer, please add the missing licenses of: OpenSceneGraph/examples/osgAndroidExampleGLES2/src/osg/AndroidExample/EGLview.java to debian/copyright. Thanks to you for catching this! (and for reviewing and approving the package). Hopefully will be fixed soon when moved to unstable. Cheers. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#607969: sqlite: Still useful?
Control: severity -1 serious Hi, I stumbled upon this bug by chance when looking at why it did not compile in some new ports. Raising severity so at the very least it gets auto-removed from testing and thus it does not get included in the next stable release (it already was included in the last, despite opinions in this bug about the contrary). I guess that it's better to just ask FTP masters to remove the package, but I'll leave that to other people, since they were interested in doing that in the past (all in copy now). Cheers. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732424: NMU for gstreamer0.10, FTBFS due to changes in bison3
Control: tags -1 + pending Hi, I am preparing a NMU to fix the bugs above (see headers), with the fix proposed by Tobias Hansen picking a patch from upstream, and with immediate upload as per guidelines in [1] as soon as I get it to work -- since they are FTBFS and severity serious, open for many months and didn't receive any update from the maintainers. There is gstreamer1.0 since a few months ago in unstable, and perhaps is the one intended that packages use from now on, but many packages still build-depend on this one. Apart from the obvious problem of FTBFS for the architectures in which it was built in the past, this is a problem for ports being added recently (OpenRISC/or1k, ppc64el, ...) since they don't even have older versions to rely on, and many packages depend on them, so it's blocking a good portion of the archive to compile cleanly. [1] http://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu Cheers. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#749944: build ogre-1.9 against new boost-defaults 1.55?
Control: forwarded -1 https://ogre3d.atlassian.net/browse/OGRE-420 2014-06-13 6:21 GMT+01:00 Scott Howard showard...@gmail.com: block 744171 by 749944 thanks On Sun, Jun 1, 2014 at 12:29 PM, Manuel A. Fernandez Montecelo manuel.montez...@gmail.com wrote: I don't know if I mention this to them in the past. It happened in a time when development was not very active and the old leader had to retire for some reason, I think. Since then, I submitted bugs that they fixed like inclusion of 3rd party library code, co-installability of different versions, support for new ports, etc. I will forward this to them hopefully soonish (but not now). If somebody beats me to it, I will not complain! :-) Cheers and thanks for your help. Thank you, sounds reasonable. FYI: freeorion FTBFS too. Putting a block on the transition bug so it shows up on their radar too. https://buildd.debian.org/status/package.php?p=freeorion I just uploaded a version depending on libboost*-dev, without versions (and closing this bug report); and forwarded the bug report upstream (URL above) as follow-up action, as per discussed previously. I am aware that setting this as forwarded and closing at the same time is a bit contradictory, but the main issue requested is fixed and I wanted to document the upstream bug somewhere. If from the discussion with upstream this requires a follow up in the mid-long term, I will open another bug report to better track its development. Cheers. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739460: openscenegraph: diff for NMU version 3.2.0~rc1-5.1
Hi Reinhard, 2014-05-17 22:30 GMT+01:00 Reinhard Tartler siret...@tauware.de: Package: openscenegraph Version: 3.2.0~rc1-5 Severity: normal Tags: patch pending Dear maintainer, I've prepared an NMU for openscenegraph (versioned as 3.2.0~rc1-5.1) and uploaded it to DELAYED/02. Please feel free to tell me if I should delay it longer. The patch provided for the older bug (687332) was sent only a week ago, part of the information/testing provided based on a derivative and not Debian, with not very popular desktops/setups, and (original author said) untested and not sure if this should be considered an openscenegraph bug or an Xfce bug . The patch might fix the issue for flightgear, but it can have widespread consequences and may beak other applications within Debian or in user's systems using the library for other purposes which happen to rely on this behaviour, so it's not something to include lightly and without asking upstream, for example. The package is not unmaintained, so you should not include fixes for minor bugs unrelated to the main purpose of fixing the RC/important bugs in general. See How confident are you about your changes? in the NMU section of Developer Reference Guide. So, can you please remove that change in the NMU, if you want to keep the NMU at all? Apart from that, the NMU was reopened ~7 days ago without any explanation about the transition until ~5 days ago (Sebastian Ramacher). It would not have hurt to ask first about the plans to fix the RC bug (which we were already discussing in private and group mailing lists), or give more than 2 days period, specially if you are including more changes than for the RC bug. Cheers. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739460: openscenegraph: diff for NMU version 3.2.0~rc1-5.1
2014-05-18 12:10 GMT+01:00 Reinhard Tartler siret...@tauware.de: 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. From my side, I have no objection that the NMU goes ahead if it contains only the fix for libav. I don't know if Alberto has any objection or plans to fix this himself, so please wait at least until 20th for his reply. Apart from that, the NMU was reopened ~7 days ago without any explanation about the transition until ~5 days ago (Sebastian Ramacher). It would not have hurt to ask first about the plans to fix the RC bug (which we were already discussing in private and group mailing lists), or give more than 2 days period, specially if you are including more changes than for the RC bug. Well, that's exactly what Sebastian did in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739460#44, without visible response. So what are your plans regarding #739460? FYI, in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739079#82, proposed a timeline that allows 0-days NMUs for bugs like #739460 starting from tomorrow. Thanks for responding and keeping the bugs with up-to-date information. As I said above, my only issue is that it does not apply to changes other than to fix the specific problem of the transition. We made several uploads this year, so the package maintainers are active. Also, I pointed that the reply from Sebastian was less than 5 days ago, which is not a whole lot of time all things considered (I was travelling yesterday all day, so could not reply to pending questions from Alberto, for example). And I don't have room in my computer to build OSG at the moment, which is kind of a problem to get this fixed :-) I understand the desire of getting through the transitions quickly, and I appreciate your work and others to get things running quickly and helping maintainers, though. We didn't object to your NMU to experimental, and neither I nor probably Alberto are against fixing the libav issue -- instead, we thank you for it. About plans. We were thinking if to continue with the current version (which is an ~rc1 immediately obsoleted by other changes), or upload a new version (which maybe has already support for libav10, so would not need patches). As things are now, I think that it's better not to upload a new version to not delay this transition, and just upload a fix for the libav transition. I can try to build it in another computer, but if somebody beats me to it, I will not complain. Cheers. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741795: tdl: FTBFS: inter.c:559:3: error: unknown type name 'Function'
Hi,
From Bug Squashing Party, I am about to upload an NMU version to fix
this package building against recent versions of libreadline.
NMU diff attached.
Cheers.
--
Manuel A. Fernandez Montecelo manuel.montez...@gmail.com
diff -u tdl-1.5.2/debian/changelog tdl-1.5.2/debian/changelog
--- tdl-1.5.2/debian/changelog
+++ tdl-1.5.2/debian/changelog
@@ -1,3 +1,11 @@
+tdl (1.5.2-3.2) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Support newer versions of libreadline, fix FTBFS: inter.c:559:3:
+error: unknown type name 'Function' (Closes: #741795)
+
+ -- Manuel A. Fernandez Montecelo m...@debian.org Sat, 22 Mar 2014 13:54:20
+
+
tdl (1.5.2-3.1) unstable; urgency=low
* Non-maintainer upload.
only in patch2:
unchanged:
--- tdl-1.5.2.orig/inter.c
+++ tdl-1.5.2/inter.c
@@ -556,7 +556,11 @@
static char *interactive_text_readline(char *prompt, char *initval, int
*is_blank, int *error)/*{{{*/
{
char *line;
+#if defined(_RL_FUNCTION_TYPEDEF)
+ rl_hook_func_t *old_rl_pre_input_hook = NULL;
+#else
Function *old_rl_pre_input_hook = NULL;
+#endif
*error = 0;
old_rl_pre_input_hook = rl_pre_input_hook;
@@ -633,9 +637,15 @@
#ifdef USE_READLINE
if (isatty(0)) {
char *result;
+#if defined(_RL_FUNCTION_TYPEDEF)
+rl_attempted_completion_function = (rl_completion_func_t *)
null_tdl_completion;
+result = interactive_text_readline(prompt, initval, is_blank, error);
+rl_attempted_completion_function = (rl_completion_func_t *) tdl_completion;
+#else
rl_attempted_completion_function = (CPPFunction *) null_tdl_completion;
result = interactive_text_readline(prompt, initval, is_blank, error);
rl_attempted_completion_function = (CPPFunction *) tdl_completion;
+#endif
return result;
} else {
/* In case someone wants to drive tdl from a script, by redirecting stdin
to it. */
@@ -653,7 +663,11 @@
#ifdef USE_READLINE
if (isatty(0)) {
rl_completion_entry_function = NULL;
+#if defined(_RL_FUNCTION_TYPEDEF)
+rl_attempted_completion_function = (rl_completion_func_t *) tdl_completion;
+#else
rl_attempted_completion_function = (CPPFunction *) tdl_completion;
+#endif
interactive_readline();
} else {
/* In case someone wants to drive tdl from a script, by redirecting stdin
to it. */
Bug#704786: Please upgrade OGRE dependency to 1.9 when upstream ready
Hi, OGRE 1.9 is in unstable and testing and apparently without major problems for 3 months. In principle, I would like to ship only 1.9 for Jessie, and not 1.8. I don't think that they will make more releases for 1.8, so it means that it's already out of support from upstream. The freeze will happen just over 6 months from now, so there's still plenty of time and no immediate rush; but it would be nice to have things stablilised and ogre-1.8 removed well before that. So it would be great if you could start compiling your packages against ogre-1.9, if supported by the respective upstreams. Cheers. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734368: libstatgrab ftbfs from source, test failures on many architectures
Hi, I'm planning to NMU this because affects my package razorqt. I would like to do it ASAP since this is already failing for 2 months and the fix seems straightforward (but still testing it), if possible this weekend (if you reply and agree), or otherwise upload to delayed queue. Cheers. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734368: libstatgrab ftbfs from source, test failures on many architectures
2014-03-08 16:21 GMT+00:00 Manuel A. Fernandez Montecelo
manuel.montez...@gmail.com:
Hi,
I'm planning to NMU this because affects my package razorqt.
I would like to do it ASAP since this is already failing for 2 months
and the fix seems straightforward (but still testing it), if possible
this weekend (if you reply and agree), or otherwise upload to delayed
queue.
Tested in powerpc porterbox, diffs of patch and NMU attached, and uploaded.
I decided to upload immediately (hope that it's OK, it abides to the
guidelines in [1]), the urgency being because:
a) the package never built in most of the architectures since the last
upload with the new upstream version, more than 2 months ago, and the
change is unlikely to break anything;
b) this RC bug has been submitted shortly thereafter and also not
fixed, triaged or has any comments for more than 2 months (so there's
no indication that it's being worked on);
c) the last version (new upstream) introduced a transition that made
rev-depends FTBFS in the first place;
d) at least my package, which depends on this, is going to be
auto-removed from testing in the couple of weeks because of this if
not fixed, so I want to get both libstatsgrab and my package razorqt
fixed and migrated to testing before the autoremoval happens;
e) and crucially, the change is quite trivial and minimal, and should
not cause any breakage by itself; but if it does I want to fix it ASAP
(e.g. this weekend better than during the week).
Cheers.
[1]
http://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu-guidelines
--
Manuel A. Fernandez Montecelo manuel.montez...@gmail.com
diff -Nru libstatgrab-0.90/debian/changelog libstatgrab-0.90/debian/changelog
--- libstatgrab-0.90/debian/changelog 2013-12-25 18:30:19.0 +
+++ libstatgrab-0.90/debian/changelog 2014-03-08 17:53:09.0 +
@@ -1,3 +1,11 @@
+libstatgrab (0.90-1.1) unstable; urgency=high
+
+ * Non-maintainer upload.
+ * Fix tests causing FTBFS in some arches due to failing to find
+/etc/mtab fix-ftbfs-734368.patch (Closes: #734368)
+
+ -- Manuel A. Fernandez Montecelo m...@debian.org Sat, 08 Mar 2014 16:42:36
+
+
libstatgrab (0.90-1) unstable; urgency=low
* New upstream version.
diff -Nru libstatgrab-0.90/debian/patches/fix-ftbfs-734368.patch
libstatgrab-0.90/debian/patches/fix-ftbfs-734368.patch
--- libstatgrab-0.90/debian/patches/fix-ftbfs-734368.patch 1970-01-01
01:00:00.0 +0100
+++ libstatgrab-0.90/debian/patches/fix-ftbfs-734368.patch 2014-03-08
17:10:11.0 +
@@ -0,0 +1,18 @@
+Description: Fix FTBFS in many arches due to FS tests
+ The cause is that it cannot find /etc/mtab (or equivalent) in some arches.
The
+ new standard place for this is '/proc/self/mounts'. ./configure
+ --with-mnttab='/proc/self/mounts' does not seem to work.
+Author: Manuel A. Fernandez Montecelo m...@debian.org
+Last-Update: 2014-03-08
+Bug-Debian: http://bugs.debian.org/734368
+--- a/src/libstatgrab/disk_stats.c
b/src/libstatgrab/disk_stats.c
+@@ -807,7 +807,7 @@
+ # endif
+ # endif
+ # ifndef MNT_MNTTAB
+- static const char *mnttabs[] = { /etc/mnttab, /etc/mtab };
++ static const char *mnttabs[] = { /proc/self/mounts, /etc/mnttab,
/etc/mtab };
+ unsigned i;
+ # endif
+ #elif defined(WIN32)
diff -Nru libstatgrab-0.90/debian/patches/series
libstatgrab-0.90/debian/patches/series
--- libstatgrab-0.90/debian/patches/series 1970-01-01 01:00:00.0
+0100
+++ libstatgrab-0.90/debian/patches/series 2014-03-08 13:45:08.0
+
@@ -0,0 +1 @@
+fix-ftbfs-734368.patch
Description: Fix FTBFS in many arches due to FS tests
The cause is that it cannot find /etc/mtab (or equivalent) in some arches. The
new standard place for this is '/proc/self/mounts'. ./configure
--with-mnttab='/proc/self/mounts' does not seem to work.
Author: Manuel A. Fernandez Montecelo m...@debian.org
Last-Update: 2014-03-08
Bug-Debian: http://bugs.debian.org/734368
--- a/src/libstatgrab/disk_stats.c
+++ b/src/libstatgrab/disk_stats.c
@@ -807,7 +807,7 @@
# endif
# endif
# ifndef MNT_MNTTAB
- static const char *mnttabs[] = { /etc/mnttab, /etc/mtab };
+ static const char *mnttabs[] = { /proc/self/mounts, /etc/mnttab, /etc/mtab };
unsigned i;
# endif
#elif defined(WIN32)
Bug#734368: marked as done (libstatgrab ftbfs from source, test failures on many architectures)
2014-03-08 18:39 GMT+00:00 Bartosz Feński bart...@fenski.pl: Thank you. I'm on medical leave for almost a month. Feel free to do any further NMUs. Sorry to hear that, I hope that you recover soon. Regarding this NMU, it already built successfully in the architectures where it was failing before (all except hurd and kfreebsd ones, where it never built successfully in the past). My package razorqt (which depends on this library) is also building successfully on those where it was uninstallable before, so I guess that everything went fine. BTW, there's a transition open related to this: https://release.debian.org/transitions/html/auto-libstatgrab.html Cheers, and again, I hope that you get well soon. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740428: src:k3d: please update Build-Depends for superlu transition
2014-03-01 13:40 GMT+00:00 Sébastien Villemot sebast...@debian.org: Le samedi 01 mars 2014 à 14:22 +0100, Julien Cristau a écrit : On Sat, Mar 1, 2014 at 14:16:21 +0100, Sébastien Villemot wrote: Package: src:k3d Version: 0.8.0.3-3 Severity: serious Tags: patch Dear Maintainer, k3d currently build-depends on libsuperlu3-dev, which has been dropped in the last superlu upload. That build-dependency should be replaced by libsuperlu-dev. I verified that k3d compiles fine after this change. Why was libsuperlu3-dev not retained as a transitional or virtual package? Because the ftpmasters did not suggest this when they requested to drop the version number from the -dev package name, and I did not come up with that idea myself :) More seriously, it's probably still possible to implement this solution if you think it's worth it. The benefits are nevertheless limited, given the small size of the transition and the work already done. Essentially, this will save a sourceful upload of k3d and getfem++. I don't mind much to change to libsuperlu-dev. Is this future-proof, for the foreseeable future? Or there are plans for the -dev be versioned again in the near future? Also, k3d doesn't show up in the transitions page for superlu, and the transition doesn't show up in K3D's PTS page :-? Cheers. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735785: ogre-1.8: FTBFS: Could not locate FREETYPE
2014-02-11 13:24 GMT+00:00 Manuel A. Fernandez Montecelo manuel.montez...@gmail.com: 2014-02-11 12:38 GMT+00:00 Hideki Yamane henr...@debian.or.jp: Control: tags -1 -fixed-upstream +patch Hi, On Tue, 11 Feb 2014 11:49:45 + Manuel A. Fernandez Montecelo manuel.montez...@gmail.com wrote: There already exists src:ogre-1.9, up to date w.r.t. upstream, and present in unstable for a few months. Oops, it's my mistake, investigation is not enough. src:ogre-1.8 should be fixed if possible anyway, there are rdepends which didn't move onto 1.9 (and probably not all of their upstreams are ready). Okay, then I've created patch for it, please review and consider to apply it :) Thanks, but there's an upstream patch in ogre-1.9 that fixes this and supports more versions, so I think that I will include that one. Uploading as we speak. But I wanted to thank you specially. Thanks for bringing this to my attention (and proposing the patch), I was sidetracked with other work in Debian. Cheers. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735785: ogre-1.8: FTBFS: Could not locate FREETYPE
2014-02-11 10:54 GMT+00:00 Hideki Yamane henr...@debian.or.jp: Control: tags -1 +fixed-upstream Hi, New upstream 1.9.0 release fixes this issue, you can get it from https://bitbucket.org/sinbad/ogre/downloads # However, it's necessary to deal with other issues (not ogre-1.8 but 1.9, etc) There already exists src:ogre-1.9, up to date w.r.t. upstream, and present in unstable for a few months. src:ogre-1.8 should be fixed if possible anyway, there are rdepends which didn't move onto 1.9 (and probably not all of their upstreams are ready). Cheers. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735785: ogre-1.8: FTBFS: Could not locate FREETYPE
2014-02-11 12:38 GMT+00:00 Hideki Yamane henr...@debian.or.jp: Control: tags -1 -fixed-upstream +patch Hi, On Tue, 11 Feb 2014 11:49:45 + Manuel A. Fernandez Montecelo manuel.montez...@gmail.com wrote: There already exists src:ogre-1.9, up to date w.r.t. upstream, and present in unstable for a few months. Oops, it's my mistake, investigation is not enough. src:ogre-1.8 should be fixed if possible anyway, there are rdepends which didn't move onto 1.9 (and probably not all of their upstreams are ready). Okay, then I've created patch for it, please review and consider to apply it :) Thanks, but there's an upstream patch in ogre-1.9 that fixes this and supports more versions, so I think that I will include that one. Cheers. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#720816: openscenegraph uninstallable
2013/12/11 Rebecca N. Palmer r.pal...@bham.ac.uk: On 12/11/13 20:59, Manuel A. Fernandez Montecelo wrote: We will discuss it and come up with a plan. Did you decide anything? As the libav transition has now been completed, this bug makes openscenegraph uninstallable. If the problem is that you are busy elsewhere, would you be happy with someone else NMUing the minimal patch (already in Ubuntu, https://launchpad.net/ubuntu/+source/openscenegraph/3.2.0~rc1-1ubuntu1 ; their armhf FTBFS is a long-standing GL-vs-GLES issue that doesn't affect Debian) to get things working again? We decided that we would wait a bit to see if the last -rc became final, to avoid unneeded breakages/binNMUs, etc. in the case that they changed the ABI or even API again. This was also partially motivated because of the breakage in alioth which happened around that time. I don't know if Alberto knows the plans of upstream (maybe a Christmas present? :-) ), but I think that the last -rc was almost 2 months ago, the more that it goes on the most likely that they disrupt something. OTOH we cannot wait indefinetly from them. I will be on holidays next week, with more time for uploads and so on. Cheers. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#720816: openscenegraph: FTBFS with libav9: FFmpegDecoder.cpp:282:76: error: 'url_feof' was not declared in this scope
2013/11/12 Steven Chamberlain ste...@pyro.eu.org: The current cause of this blockage is actually problems/delays in MIPS toolchain and bad timing. If you mean the delayed build of openscenegraph on mips, happening after libav9 transition started, I'm not sure that makes a difference because it would be stuck until rdepends are ready (and they're still not). libav9 transition started only a few days later so openscenegraph would have failed on *all* arches when binNMUd? That's correct, I was trying to set the matter in perspective, and why the breakage occured in OSG without us being notified by libav people. I uploaded the last OSG package on ~8th of August, around which date most buildds built it successfully. mips didn't try to build until the 26th, when it failed to build for other reasons (buildd fault, not the package), and the 29th when it failed to build due to the new libav9 being there (it was uploaded in mid August). We didn't have any warning in the BTS or by email of the libav9 affecting OSG, excep possibly the PTS, cannot remember. Even if we had in the PTS, certainly nobody rebuilt OSG against the newer libav9 and tell us that it would break, offering help or suggesting patches (before the breakage). So I only noticed this by the end of August with #720816 after a archive-wide rebuild of all packages in sid (amd64). Granted, the archive is getting big and some of these packages are big, but still we did that for our upgrade of OSG with our rdepends; and I built not long ago ~450 pages with rdepends to libsdl to check for possible breakages of important changes. Which bring us to the following point: 5) So as a summary and in short, having an open transition process is not going to speed-up the transition [...] (libcitygml didn't respond or upload for more than 3 months, for example). Conversely, that's why I suggested having a tracker; having more eyes on the problem and making it easier to see what needs to happen. So even when transition trackers are set up, as it was the case with libav9 (just picking the example at hand, nothing particularly bad), this doesn't help to avoid breakages, and libav maintainers were less pro-active than us in warning rdepends. Informing rdepends, sending patches and eventually NMUing if feasible and maintainers inactive or removing from the archive (if the packages are hopeless) are the things that can move things forward. So I still don't think that having a tracker is not useful in our case (mostly bureaucracy and a waste of time, IMO). Since the transition requested already mentions libopenscenegraph100, but 3.2.1 is not released, I think that it's actually more risky (or prone to more delays) if to tie the current transition to these future ones of OSG. ... the tracker will need updating with whatever you decide to aim for (99 or 100). I would think 99 is the quickest and safest resolution to the libav9 tangle. As Rebecca said, it implies another round of binNMUs as soon as 3.2.1 is uploaded. But IMHO that will be much easier and less urgent if nothing else is waiting on it by then. Are you decided that you are aiming for libopenscenegraph99 to migrate first? A change in package names, such as libopenscenegraph99-100 or libopenthreads to whatever SOVERSION, will force the package to go through the new queue, so it's not the speediest of the routes. OTOH there're many other packages, and much more important than OSG, still pending to be built against libav9, so I don't think that this is so urgent though, and also depends on what happens with 3.2.1. We will discuss it and see what to do. Cheers. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#720816: openscenegraph: FTBFS with libav9: FFmpegDecoder.cpp:282:76: error: 'url_feof' was not declared in this scope
2013/11/12 Rebecca N. Palmer r.pal...@bham.ac.uk: I now see that these [reverse dependencies] packages are 'sid only', They're sid-only because this transition stalled for long enough for its FTBFS bugs to trigger the autoremover. Is that an autoremover bug or a feature? It is a feature, removes packages which are not fit for release for one reason or another, so helps to not delay the release of ~17 thousand source packages (or whatever number is there in the archive at the moment) for the sake of a few. When things are fixed in OSG (in this case) or other problems which kicked packages out of testing, they will happily migrate to testing automatically as long as they are fine in unstable, AFAICT. And the freeze is only on the 5th of November of next year, so there's plenty of time for more fixes and additional breakages. Since the transition requested already mentions libopenscenegraph100, but 3.2.1 is not released, I think that it's actually more risky (or prone to more delays) if to tie the current transition to these future ones of OSG. The 99-100 soname bump is 3.2.0rc-3.2.0 not 3.2.0-3.2.1 and appears to be a standard OSG release procedure (possibly intended as a don't use pre-releases in production marker) rather than a real change (https://github.com/openscenegraph/osg/commits/OpenSceneGraph-3.2?page=2, scroll down to Jul 23), so I wouldn't _expect_ further breakage, but I agree it's always possible. (E.g. building with --as-needed, which you do (as recommended), is currently unreliable on ia64: #718047) Further breakage is always possible, and even probable in the buildds of some architectures lately, or that's my recent experience anyway. As for the 99-100, I meant in previous emails to fix the FTBFS bug with the current source in unstable, not even updating to 3.2.0 / SOVERSION 100. Doing otherwise means that the packages goes through the NEW queue and this is delayed for weeks/months typically. But maybe Alberto (who follows closely upstream) will have more information or other opinion, or maybe 3.2.1 is released as we discuss it. We will discuss it and come up with a plan. Cheers. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#720816: openscenegraph: FTBFS with libav9: FFmpegDecoder.cpp:282:76: error: 'url_feof' was not declared in this scope
, but 3.2.1 is not released, I think that it's actually more risky (or prone to more delays) if to tie the current transition to these future ones of OSG. Cheers. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
