Re: Porter roll call for Debian Bookworm
Hello, 2021-10-02 11:57 Graham Inggs: Hi We are doing a roll call for porters of all prospective release architectures. If you are an active porter behind one of these architectures [1] and intend to continue for the development cycle of Debian Bookworm (est. release mid-2023), please respond with a signed email containing the following before Saturday, January 1, 2022: * Which architectures are you committing to be an active porter for? * Please describe recent relevant porter contributions. * Are you running/using Debian testing or sid on said port(s)? * Are you testing/patching d-i for the port(s)? Please note that no response is required for amd64 because our toolchain maintainers are happy to support amd64 as-is. Feel free to use the following template as your reply: [...] I have been working on the riscv64 port since 2015 or so, even if the successful and definitive initial bootstrap only happened in 2018. Some people joined from the start and more people joined lately, but I have a keen interest in pushing this port further :) Thus, I am an active porter for riscv64 and I intend to continue for the development cycle of Debian Bookworm (est. release mid-2023). In the last year or two the contributions were a bit diminished for a variety of issues (especially in the realm of attending bugs and looking at specific issues of packages and submitting patches), and will continue to be this way for a while, but I hope to pick-up pace again during this development cycle. For riscv64, I plan to: - maintain buildds --- I have set-up or was involved in getting hardware and necessary resources and setting up most of the buildds of the architecture so far, and I plan to continue doing this in the foreseeable future - maintain/provide hardware for (or assist with) automated tests on ci.d.n, jenkins.d.n (etc.) --- I though about doing do this in the past, I think that it's a good idea to do this if new suitable hardware becomes available, but there's been scarcity until now. - run a Debian testing or unstable system on port that I use regularly - test (most|all) packages on this architecture --- not sure if saying (most|all) is realistic with the current size of the archive, but I hope to use regularly the most important packages by using them on real systems. The following I will try to do as more time becomes available, and paying more attention if this port is considered to be supported for bookworm and becoming a more official architecture (but other people with interest in riscv64 are also working on these areas): - fix toolchain issues - triage arch-specific bugs - fix arch-related bugs - triage d-i bugs - test d-i regularly - fix d-i bugs/issues I am a DD. -- Manuel A. Fernandez Montecelo signature.asc Description: PGP signature
Re: MPICH as default MPI; WAS: MPI debugging workflows
Hi,
Em qua, 3 de out de 2018 às 16:24, Mattia Rizzolo escreveu:
>
> On Wed, Oct 03, 2018 at 02:02:25PM +0100, Alastair McKinstry wrote:
> > Any ideas on how to write the ben tracker script? I think it would work by
> > looking for packages with binaries linked to openmpi rather than mpich, but
> > there are a number of packages that would be false positives (HDF5,
> > open-coarrays, etc. ) that build against both.
>
> The bug report I linked in mpi-defaults' README.source contains an
> example.
>
> the false positives could be just handled manually (i.e. listed in the
> transition bug), I don't think there are many that links to both.
>
> Also, please note that mpich never built on riscv64, and is not up2date
> on hppa and ppc64. I think at least the riscv64 should be handlded
> first, so to avoid being in the same situation again when a single weird
> architecture uses a different MPI implementation.
> I'm CCing debian-ri...@lists.debian.org for this, in case you need help.
>From the riscv64 camp, I built the current version in hardware and
uploaded to "unreleased" in debian-ports:
mpich_3.3~b3-2_riscv64.changes
I suspect that the reason why it doesn't build is timeout in the
tests, due to the buildds being qemu-system. The timeout can be
increased with environment variables:
test/mpi/runtests.in:if (defined($ENV{"MPITEST_TIMEOUT"})) {
test/mpi/runtests.in:$defaultTimeLimit = $ENV{"MPITEST_TIMEOUT"};
test/mpi/runtests.in:if (defined($ENV{"MPITEST_TIMEOUT_MULTIPLIER"})) {
test/mpi/runtests.in:$defaultTimeLimitMultiplier =
$ENV{"MPITEST_TIMEOUT_MULTIPLIER"};
We can try to send a patch if it helps.
Cheers.
--
Manuel A. Fernandez Montecelo
Re: Arch qualification for buster: call for DSA, Security, toolchain concerns
2018-06-30 14:27 GMT+02:00 Paul Wise : > On Sat, Jun 30, 2018 at 7:44 AM, Manuel A. Fernandez Montecelo wrote: > >> People from DSA have also attempted to fix them in other ways over the >> last few months (thanks for that too!), but the solutions have been >> rejected. I am not aware of the full details (only part of them), but >> I assume that it's done for sound reasons. One good reason for this >> is that they don't want to duplicate code or list of architectures. > > The details here is that aurel32 wrote a git branch to add > architecture configurability in dak and hard-code a list of > "arches-in-sid-dpkg" in such a configuration file. ftp-master > understandably didn't want to have to manually copy the tables from > dpkg to dak whenever they changed. I briefly looked at using an > auto-byhand script to automate this, but didn't yet get around to > working on implementing anything. > > https://salsa.debian.org/aurel32/dak/tree/dpkg-tables For completeness and as a way to acknowledge the effort, waldi had another stab at it in the last couple of weeks: https://salsa.debian.org/ftp-team/dak/merge_requests/81 In summary, even if as of today the problem is not yet solved, I think that it's fair to say that there were many pushes to move it forward from different fronts -- there were several attempts to address the problem by different people at different times and in different ways; including dak/archive and DSA, dpkg, and release team with stable-updates. Cheers. -- Manuel A. Fernandez Montecelo
Re: Arch qualification for buster: call for DSA, Security, toolchain concerns
Hi, 2018-06-29 11:35 GMT+02:00 Adam D. Barratt : > On Fri, 2018-06-29 at 10:20 +0100, Luke Kenneth Casson Leighton wrote: > [...] >> what is the reason why that package is not moving forward? > > I assume you're referring to the dpkg upload that's in proposed-updates > waiting for the point release in two weeks time? Please check your > facts before ranting, particularly with such a wide cross-posting. Yep, this changed in the last few days. Thanks to the people involved! It's not guaranteed that this version will be part of the final update 9.5, but let's hope that no blocker appears. People from DSA have also attempted to fix them in other ways over the last few months (thanks for that too!), but the solutions have been rejected. I am not aware of the full details (only part of them), but I assume that it's done for sound reasons. One good reason for this is that they don't want to duplicate code or list of architectures. > Also, ttbomk, the dpkg change landing in stable is not likely to > magically lead to the architecture being added to unstable - a decision > which is not the release team's to make or block. Again, please ensure > you've actually done your research. I think that there's some confusion related to this. I am not sure if everyone is on the same page about what "added to unstable" means. At the risk of failing to enlighten and make matters worse, let me try. The packages uploaded to unstable now (since ~March) are attempted to build automatically in riscv64, and most of them succeed, just over 80%. Most of the remaining missing packages are because of lack of support upstream that blocks this big chunk of the archive for one reason or another. The problem which involves this dpkg-in-stable-updates topic is that some packages need to add the string "riscv64" in Architecture fields to be able to build, but they cannot be uploaded to unstable with such modification, because they would be auto-rejected by the archive software "dak", which relies on dpkg's knowledge of architectures for this (the dpkg installed on the system, not from git or anywhere else). This is the case of, among other packages, "binutils", "glibc" or "linux", and we need to build them specially adding "riscv64" in specific places, and upload to another suite which is not "unstable" (named "unreleased", which probably many people never heard of). This is problematic mainly for two reasons: - needs human intervention, repeatedly - "debootstrap" for example, the most widely used tool for creating chroots and the base of images, cannot work. This is because it is restricted to one URL, so it cannot use both suites unstable+unreleased at the same time, and some of the packages that I mentioned before are needed in any base system [*]. Now, if a dpkg version with knowledge about riscv64 architecture enters an stable-update and the systems running "dak" do apply the upgrade, "dak" will start accepting these packages, so we can request that maintainers add support for riscv64, so they don't need human intervention and it'll save significant amounts of pointless work, and will automatically make the port to be more up-to-date with these packages that cannot build. Some people like the binutils maintainer already did the biggest part of the job long ago, and it's much easier for us after that, but they cannot add this last bit until this problem is resolved somehow. If this doesn't work for some reason (e.g. a blocker bug to this version of dpkg that prevents actually becoming part of the stable-update), we will have to keep doing this pointless work at least until a year from now, with the next stable. [*] Maybe there are more packages from the base set installed by debootstrap which would prevent this for other reasons, but these packages for sure are the biggest problem right now. > I'm also getting very tired of the repeated vilification of SRM over > this, and if there were any doubt can assure you that it is not > increasing at least my inclination to spend my already limited free > time on Debian activity. Sorry about that :( I don't think that it's a problem caused SRM by other parts in particular, and I am sorry that you get vilified for this. >From a more distanced view, it would be nice though for other ports in the future if dak's knowledge about architectures could be decoupled from "dpkg-version-in-stable", and no other parts were too coupled in general to versions of packages from stable. The very nature of ports means that sometimes they need features not present in packages by the time that they entered stable. Cheers. -- Manuel A. Fernandez Montecelo
Bug#890791: stretch-pu: package dpkg/1.18.25
Hi, 2018-04-20 1:52 GMT+02:00 Guillem Jover <guil...@debian.org>: > Hi! > > On Wed, 2018-02-28 at 18:45:49 +, Adam D. Barratt wrote: >> On Wed, 2018-02-28 at 16:05 +0100, Manuel A. Fernandez Montecelo wrote: >> > 2018-02-18 22:26 Guillem Jover: >> > > I'd like to update dpkg in stretch. This includes several fixes for >> > > documentation, regressions, misbheavior, minor security issues, and >> > > a new arch definition so that DAK can accept packages using it. The >> > > fixes have been in sid/buster for a while now. >> > >> > We depend on this version being accepted and installed in the systems >> > where DAK lives to learn about the new architecture. After that, >> > several other packages can add support for the architecture, without >> > receiving an automatic reject when uploaded. >> > >> > It would be great if this update could enter in the next stable >> > update, so we can make progress on that front. > >> We've been discussing this amongst the SRMs and are quite wary of a >> dpkg update this close to the p-u freeze. We appreciate that the >> changes individually seem self-contained but would like to have an >> update of such a key package able to be tested more than is feasible in >> the time available. >> >> (On a related note, in practical terms it's very unlikely that there >> would be sufficient time to get the new strings that are introduced >> translated.) > > Is there perhaps anything you are waiting for me to do here? > > For the strings I realized afterwards I can take the ones from sid. > I've not yet checked how many, or if I'd really need a call for > translation, but I'd rather do that only after I know which parts you > are going to accept. :) But TBH, this being gettext I'm not sure it > matters that much, as only those strings might end up not being > translated and dpkg does not have 100% coverage for all languages > anyway. :) Thanks Guillem. So in the 2+ months since that original request, we went from scattered packages outside the Debian infrastructure to having a port in debian-ports infra, with >60% of packages built. Unfortunately, important packages like binutils, glibc or linux-* have to stay in the separate "unreleased" suite for that reason, so the lack of support in dak for riscv64 is causing us to do this extra work, which would be otherwise unneeded It would be very nice if this update could move to stable-updates to unblock the situation in a few weeks/months time. Thanks! -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#890791: stretch-pu: package dpkg/1.18.25
Hi, 2018-03-20 7:33 GMT+01:00 Karsten Merker <mer...@debian.org>: > On Wed, Feb 28, 2018 at 06:45:49PM +, Adam D. Barratt wrote: >> >> We've been discussing this amongst the SRMs and are quite wary of a >> dpkg update this close to the p-u freeze. We appreciate that the >> changes individually seem self-contained but would like to have an >> update of such a key package able to be tested more than is feasible in >> the time available. >> [...] >> We understand that this is inconvenient for the riscv porters, so are >> exploring whether it would be possible to have the dak support made >> available via p-u after the upcoming point release. > > Hello, > > I wanted to kindly ask whether there are any news on this topic > and whether there is anything that the RISC-V porters can do > to help. I pinged Guillem today, basically he's waiting for an ack of the .debdiff before uploading to proposed-updates. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#890791: stretch-pu: package dpkg/1.18.25
2018-02-28 19:45 GMT+01:00 Adam D. Barratt <a...@adam-barratt.org.uk>: > We understand that this is inconvenient for the riscv porters, so are > exploring whether it would be possible to have the dak support made > available via p-u after the upcoming point release. I'd appreciate if you can find some alternative solution for the RISC-V support, waiting to the next stable update is a bit too much, and still there's no guarantee that it'll be accepted then. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#890791: stretch-pu: package dpkg/1.18.25
block 886440 by 890791 block 888793 by 890791 block 889841 by 890791 stop Hello, 2018-02-18 22:26 Guillem Jover: Package: release.debian.org Severity: normal Tags: stretch User: release.debian@packages.debian.org Usertags: pu Hi! I'd like to update dpkg in stretch. This includes several fixes for documentation, regressions, misbheavior, minor security issues, and a new arch definition so that DAK can accept packages using it. The fixes have been in sid/buster for a while now. We depend on this version being accepted and installed in the systems where DAK lives to learn about the new architecture. After that, several other packages can add support for the architecture, without receiving an automatic reject when uploaded. It would be great if this update could enter in the next stable update, so we can make progress on that front. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#876561: transition: gdal
Hi! 2017-10-05 18:19 Sebastiaan Couwenberg: Thanks for the osgearth NMU on amd64, for the uncoordinated openscenegraph-3.4 transition it also needs to be NMUed on i386 & ppc64el (and powerpc). Sorry about that, I intended [1] to upload to experimental but failed miserably :( [1] https://anonscm.debian.org/cgit/pkg-osg/openscenegraph-3.4.git/commit/?id=5e647793462f9ea6d63c0138bfe0b89219121e6a (I think that I tend to run "dch" in a way that it doesn't work as I expect, something like "dch -r experimental" without "--distribution"... and then failed to double-check when uploading). -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#864590: unblock: aptitude/0.8.8-1 (pre-approval)
2017-06-11 10:29 GMT+02:00 Niels Thykier <ni...@thykier.net>: > > Unfortunately, we are past the deadline for anything but major bugs. > Your changes look fine and some of them may be acceptable for a stable > update. Please consider requesting one with the SRMs after the initial > stretch release. All right, I will do that. Thanks! -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#864590: unblock: aptitude/0.8.8-1 (pre-approval)
ovladače hlasitosti, MIDI sekvencery, programy pro zápis not, ovladače
zvukových zařízení a software pro zpracování zvuku.";
diff -Nru --exclude '*.po' --exclude '*.pot' --exclude 'configure*' --exclude
'*.gmo' aptitude-0.8.7/debian/changelog aptitude-0.8.8/debian/changelog
--- aptitude-0.8.7/debian/changelog 2017-04-19 00:22:12.0 +0200
+++ aptitude-0.8.8/debian/changelog 2017-06-11 01:38:34.0 +0200
@@ -1,3 +1,33 @@
+aptitude (0.8.8-1) unstable; urgency=medium
+
+ [ Manuel A. Fernandez Montecelo ]
+ * New upstream release. Please see /usr/share/aptitude/NEWS for a change
+log with more details.
+
+- User visible changes:
+ * Avoid spurious warnings about unused code paths (Closes: #863755)
+
+- Documentation improvements:
+ * Replace minimal example for configuring resolver hints with a full
+example. (Closes: #702565, part 1)
+ * Document keywords "maximum" and "minimum" for cost levels.
+(Closes: #702565, part 2)
+ * Mention in the man page that a tilde character in front of an
+order keyword reverses the order. (Closes: #814038)
+
+- Translation updates:
+ * da.po: Danish translation by Morten Bo Johansen (Closes: #861087)
+ * cs.po, aptitude-defaults.cs: Czech translation by Miroslav Kure
+(Closes: #861940)
+ * nl.po: Dutch translation by Frans Spiesschaert (Closes: #862922)
+ * Dutch documentation translation by Frans Spiesschaert (Closes: #861709)
+
+
+ * d/control: Set package priority to Optional instead of Important
+(Closes: #861425)
+
+ -- Manuel A. Fernandez Montecelo <m...@debian.org> Sun, 11 Jun 2017 01:38:34
+0200
+
aptitude (0.8.7-1) unstable; urgency=medium
[ Manuel A. Fernandez Montecelo ]
diff -Nru --exclude '*.po' --exclude '*.pot' --exclude 'configure*' --exclude
'*.gmo' aptitude-0.8.7/debian/control aptitude-0.8.8/debian/control
--- aptitude-0.8.7/debian/control 2017-04-19 00:11:13.0 +0200
+++ aptitude-0.8.8/debian/control 2017-06-11 01:27:30.0 +0200
@@ -1,6 +1,6 @@
Source: aptitude
Section: admin
-Priority: important
+Priority: optional
Maintainer: Aptitude Development Team <aptitude-de...@lists.alioth.debian.org>
Uploaders: Manuel A. Fernandez Montecelo <m...@debian.org>,
Axel Beckert <a...@debian.org>
@@ -74,7 +74,6 @@
Package: aptitude-doc-cs
Section: doc
-Priority: optional
Architecture: all
Multi-Arch: foreign
Provides: aptitude-doc
@@ -92,7 +91,6 @@
Package: aptitude-doc-en
Section: doc
-Priority: optional
Architecture: all
Multi-Arch: foreign
Provides: aptitude-doc
@@ -110,7 +108,6 @@
Package: aptitude-doc-es
Section: doc
-Priority: optional
Architecture: all
Multi-Arch: foreign
Provides: aptitude-doc
@@ -128,7 +125,6 @@
Package: aptitude-doc-fi
Section: doc
-Priority: optional
Architecture: all
Multi-Arch: foreign
Provides: aptitude-doc
@@ -146,7 +142,6 @@
Package: aptitude-doc-fr
Section: doc
-Priority: optional
Architecture: all
Multi-Arch: foreign
Provides: aptitude-doc
@@ -164,7 +159,6 @@
Package: aptitude-doc-it
Section: doc
-Priority: optional
Architecture: all
Multi-Arch: foreign
Provides: aptitude-doc
@@ -182,7 +176,6 @@
Package: aptitude-doc-ja
Section: doc
-Priority: optional
Architecture: all
Multi-Arch: foreign
Provides: aptitude-doc
@@ -200,7 +193,6 @@
Package: aptitude-doc-nl
Section: doc
-Priority: optional
Architecture: all
Multi-Arch: foreign
Provides: aptitude-doc
@@ -218,7 +210,6 @@
Package: aptitude-doc-ru
Section: doc
-Priority: optional
Architecture: all
Multi-Arch: foreign
Provides: aptitude-doc
diff -Nru --exclude '*.po' --exclude '*.pot' --exclude 'configure*' --exclude
'*.gmo' aptitude-0.8.7/doc/en/aptitude.xml aptitude-0.8.8/doc/en/aptitude.xml
--- aptitude-0.8.7/doc/en/aptitude.xml 2017-04-04 00:28:08.0 +0200
+++ aptitude-0.8.8/doc/en/aptitude.xml 2017-05-18 23:20:14.0 +0200
@@ -7,7 +7,7 @@
dselect'>
apt-get'>
root'>
-
+
@@ -4922,6 +4922,15 @@
for details. The default levels are illustrated in .
+
+
+Besides numbers you can also use the keywords
+maximum and
+minimum for cost
+levels. They refer to the maximal respective minimal
+integer value possible on the hardware architecture of
+your system.
+
@@ -5178,9 +5187,10 @@
target, the hint affects
the decision to remove
target. For instance,
- reject aptitude
- :UNINST will prevent the resolver
- from attempting to remove .
+ Aptitude::ProblemResolver::Hints {
+"reject aptitude :UNINST"; }; will
+prevent the resolver from attempting to remove
+.
diff
Bug#860586: unblock: aptitude/0.8.7-1 (pre-approval)
Control: tags -1 - moreinfo Hi, 2017-04-21 15:27 GMT+02:00 Niels Thykier <ni...@thykier.net>: > > Unblocked, thanks. Thanks for approving. It built everywhere except mips64el, it often has problems building there (some of the machines make xsltproc or elinks or something like thatcannot build it properly). It started to build again, so maybe it succeeds this time; failing that I will try to sort it out. But just to let you know, in the case that you want to reopen the bug until it's built there. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#860389: unblock: dhcpdump/1.8-2.1 (pre-approval)
Control: tags -1 - moreinfo Hi Niels, 2017-04-18 10:39 Niels Thykier: Please go ahead and let me know once it has been built successfully in unstable on all relevant release architectures. Thanks. It has built successfully on all arches, -ports included, except sh4 (not attempted yet, long queue). -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#860586: unblock: aptitude/0.8.7-1 (pre-approval)
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Hello,
I know that we're very late in the preparation of the release, but still I
submit this for your consideration.
I am quite happy with aptitude as it is now in stretch, but still I think that
it'll be a bit better with these changes than without them.
Due to $LIFE and $CIRCUMSTANCES I could not work too much on aptitude lately,
but in the last few days I fixed some things that are important for some people
(e.g. FAI), fixed some bugs that appeared in some cases after the last Debian
release due to other changes within aptitude, in other cases due to changes in
the apt "ecosystem", and in yet another case it was a bug present for a very
long time, maybe more than a decade; and lastly doc translation update.
>From my (biased) POV, these changes are not very risky/intrusive, all changes
can be reverted without much trouble if need be, and I expect to be available in
the next weeks for quick fixes if necessary.
I send attached the debdiff (filtering out po files of code and documentation),
but perhaps it's better/easier to review the individual changes in the VCS.
unblock aptitude/0.8.7-1
Cheers.
diff -Nru --exclude '*.po' --exclude '*.pot' --exclude 'configure*' --exclude
'*.gmo' aptitude-0.8.6/debian/changelog aptitude-0.8.7/debian/changelog
--- aptitude-0.8.6/debian/changelog 2017-03-05 23:19:57.0 +0100
+++ aptitude-0.8.7/debian/changelog 2017-04-19 00:22:12.0 +0200
@@ -1,3 +1,26 @@
+aptitude (0.8.7-1) unstable; urgency=medium
+
+ [ Manuel A. Fernandez Montecelo ]
+ * New upstream release. Please see /usr/share/aptitude/NEWS for a change
+log with more details.
+
+- User visible changes:
+ * Warn about invalid locales (Closes: #859907)
+
+- Bug fixes:
+ * Preserve auto-installed flag with hold/unhold/keep operations
+(Closes: #843536)
+ * [cmdline] Fix extreme slowness of keep-all (Closes: #842707)
+ * Avoid problems or improve response in problems related to reinstalling
+(Closes: #851901)
+ * [cmdline] Failing to apply actions are not fatal with -f /
+Aptitude::CmdLine::Fix-Broken (Closes: #835372)
+
+- Translation updates:
+ * Italian documentation translation by Beatrice Torracca (Closes:
#858784)
+
+ -- Manuel A. Fernandez Montecelo <m...@debian.org> Wed, 19 Apr 2017 00:22:12
+0200
+
aptitude (0.8.6-1) unstable; urgency=medium
[ Manuel A. Fernandez Montecelo ]
diff -Nru --exclude '*.po' --exclude '*.pot' --exclude 'configure*' --exclude
'*.gmo' aptitude-0.8.6/doc/en/aptitude.xml aptitude-0.8.7/doc/en/aptitude.xml
--- aptitude-0.8.6/doc/en/aptitude.xml 2017-03-05 22:26:40.0 +0100
+++ aptitude-0.8.7/doc/en/aptitude.xml 2017-04-04 00:28:08.0 +0200
@@ -7,7 +7,7 @@
dselect'>
apt-get'>
root'>
-
+
diff -Nru --exclude '*.po' --exclude '*.pot' --exclude 'configure*' --exclude
'*.gmo' aptitude-0.8.6/NEWS aptitude-0.8.7/NEWS
--- aptitude-0.8.6/NEWS 2017-03-05 22:26:40.0 +0100
+++ aptitude-0.8.7/NEWS 2017-04-18 23:58:57.0 +0200
@@ -1,3 +1,48 @@
+[2017-04-18]
+Version 0.8.7
+
+- User visible changes:
+
+ * Warn about invalid locales (Closes: #859907)
+
+- Bug fixes:
+
+ * Preserve auto-installed flag with hold/unhold/keep operations
+(Closes: #843536)
+
+ * [cmdline] Fix extreme slowness of keep-all (Closes: #842707)
+
+Every change of marking the package to "keep" was triggering a reevaluation
+in aptitudeDepCache::end_action_group() of what had changed ("mark and
sweep",
+duplicate of cache, triggers of packages state changes... etc), for every
+package.
+
+ * Avoid problems or improve response in problems related to reinstalling
+(Closes: #851901)
+
+Improvements to deal with several problems that sometimes appear when
+reinstalling or acting on scheduled reinstall actions, due to the versions
+disappearing from the repositories.
+
+ * [cmdline] Failing to apply actions are not fatal with -f /
+Aptitude::CmdLine::Fix-Broken (Closes: #835372)
+
+The behaviour of refusing to continue when there are errors happens since
+the change "[cmdline] Abort with Failure when actions cannot be taken
+(Closes: #121313, #430392, #445034, #498239, #576212, #639789, #798320)",
+but it's not an optimal solution for automatic installers like FAI, so this
+is a way to revert to the old behaviour.
+
+- Internal changes:
+
+ * new method is_version_available(), to check if the given version of a
+package is available (to check availability e.g. for reinstalls)
+
+- Translation updates:
+
+ * Italian documentation translation by Beatrice Torracca (Closes: #858784)
+
+
[2017-03-05]
Version 0.8.6
diff -Nru --exclude '*.po' --exclude '*.pot' --exclude 'configure*' --exclude
'*.gmo' aptitude-0.8.6/src/cmdline/cmdli
Bug#860391: unblock: flare-engine/0.19-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock I submitted a fix to unstable to correct an invalid symlink to a font that changed paths. It is not critical problem, but I submit this request in the case that you think that it's OK to include in the release. unblock flare-engine/0.19-3 diff -Nru flare-engine-0.19/debian/changelog flare-engine-0.19/debian/changelog --- flare-engine-0.19/debian/changelog 2015-08-01 17:46:43.0 +0200 +++ flare-engine-0.19/debian/changelog 2017-04-13 21:59:47.0 +0200 @@ -1,3 +1,9 @@ +flare-engine (0.19-3) unstable; urgency=medium + + * Fix broken symlink to a font, thanks to Andreas Beckmann (Closes: #857395) + + -- Manuel A. Fernandez Montecelo <m...@debian.org> Thu, 13 Apr 2017 21:59:47 +0200 + flare-engine (0.19-2) unstable; urgency=medium * Bump Policy Standards-Version to 3.9.6 (no changes needed) diff -Nru flare-engine-0.19/debian/rules flare-engine-0.19/debian/rules --- flare-engine-0.19/debian/rules 2015-08-01 17:23:16.0 +0200 +++ flare-engine-0.19/debian/rules 2017-04-13 21:58:00.0 +0200 @@ -15,7 +15,7 @@ override_dh_link: # Use the system-wide fonts - dh_link -- usr/share/fonts/truetype/ttf-liberation/LiberationSans-Regular.ttf usr/share/games/flare/default/mods/default/fonts/LiberationSans-Regular.ttf + dh_link -- usr/share/fonts/truetype/liberation/LiberationSans-Regular.ttf usr/share/games/flare/default/mods/default/fonts/LiberationSans-Regular.ttf # mafm 20111021 -- man page can be regenerated from time to time, no
Bug#860389: unblock: dhcpdump/1.8-2.1 (pre-approval)
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Hello, I uploaded an NMU of the dhcpdump package to experimental, with the following changes that had been submitted over time by several contributors: - fix for reproducible builds (it did build reproducibly [1]) - fix FTBFS in Hurd and kFreeBSD - fix for FTCBFS (cross-build) It was the first upload in many years, but the current version in testing is "fresh enough" -- the version was recently built for release arches due to the binNMUs for PIE. I submit this request in the case that you consider it worthy to be released with these changes in stretch -- in that case, I will move it to unstable. Cheers. [1] https://tests.reproducible-builds.org/debian/rb-pkg/experimental/amd64/dhcpdump.html diff -u dhcpdump-1.8/debian/rules dhcpdump-1.8/debian/rules --- dhcpdump-1.8/debian/rules +++ dhcpdump-1.8/debian/rules @@ -17,6 +17,8 @@ # SHELL=/bin/bash +DEB_HOST_GNU_TYPE = $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE) + # The name and version of the source # source = $(shell grep "^Source: " debian/control|head -1|sed 's/Source: \(.*\)/\1/g') @@ -27,17 +29,25 @@ installbin = install -g root -o root -m 755 installdoc = install -g root -o root -m 644 +# support non-Linux arches, see #622267 +EXTRAFLAG = $(shell dpkg-architecture -ilinux-any || echo "-D_BSD_SOURCE") + +ifeq ($(origin CC),default) +CC = $(DEB_HOST_GNU_TYPE)-gcc +endif + ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS))) CFLAGS = -g -O2 -Wall else CFLAGS = -O2 -Wall endif +STRIP = $(DEB_HOST_GNU_TYPE)-strip ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS))) -STRIP = -s +STRIP = : strip endif build: - $(MAKE) CFLAGS="$(CFLAGS) -DHAVE_STRSEP" + $(MAKE) CC=$(CC) CFLAGS="$(CFLAGS) $(EXTRAFLAG) -DHAVE_STRSEP" touch stamp-build cat debian/copyright LICENSE > copyright.txt @@ -63,14 +73,15 @@ $(installdoc) debian/changelog debian/tmp/usr/share/doc/$(package)/changelog.Debian # $(installdoc) copyright.txt debian/tmp/usr/share/doc/$(package)/copyright - gzip -9f debian/tmp/usr/share/doc/$(package)/changelog.Debian + gzip -9nf debian/tmp/usr/share/doc/$(package)/changelog.Debian # $(installbin) -d debian/tmp/usr/sbin - $(installbin) $(STRIP) dhcpdump debian/tmp/usr/sbin + $(STRIP) dhcpdump + $(installbin) dhcpdump debian/tmp/usr/sbin # $(installbin) -d debian/tmp/usr/share/man/man8 $(installdoc) dhcpdump.8 debian/tmp/usr/share/man/man8 - gzip -9 debian/tmp/usr/share/man/man?/* + gzip -9n debian/tmp/usr/share/man/man?/* # dpkg-shlibdeps debian/tmp/usr/sbin/dhcpdump dpkg-gencontrol -isp diff -u dhcpdump-1.8/debian/changelog dhcpdump-1.8/debian/changelog --- dhcpdump-1.8/debian/changelog +++ dhcpdump-1.8/debian/changelog @@ -1,3 +1,20 @@ +dhcpdump (1.8-2.1) experimental; urgency=low + + [ Manuel A. Fernandez Montecelo ] + * Non-maintainer upload. + + [ Svante Signell ] + * Fix to make dhcpdump build on GNU/Hurd (Closes: #622267) +- modified by mafm@d.o to support kFreeBSD arches + + [ Chris Lamb ] + * Fix for reproducible builds (Closes: #777309) + + [ Helmut Grohne ] + * Fix FTCBFS: use the host arch compiler (Closes: #793893) + + -- Manuel A. Fernandez Montecelo <m...@debian.org> Thu, 13 Apr 2017 17:34:33 +0200 + dhcpdump (1.8-2) unstable; urgency=low * Bump standards-version
Bug#856848: unblock: aptitude/0.8.6-1 (pre-approval)
Hi, 2017-03-05 15:15 GMT+01:00 Niels Thykier <ni...@thykier.net>: > > At first glance it looks reasonable, but could you please provide a > debdiff of the changes for a second review. Sure. For the upstream side of the changes I recommend the previous diff, but this is the full-ish debdiff (without translations and so on). debdiff --exclude '*.po' --exclude '*.pot' --exclude 'configure*' --exclude '*.gmo' aptitude_0.8.[56]-1.dsc > /tmp/aptitude-for-stretch.debdiff -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com> aptitude-for-stretch.debdiff Description: Binary data
Bug#856848: unblock: aptitude/0.8.6-1 (pre-approval)
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Hello,
I have not uploaded to unstable yet, but this is to request a pre-approval to
upload to unstable if it will be accepted for stretch.
It fixes some of the more important bugs right now in aptitude (some causing
crashes, could be even RC), some minor problems with unintursive changes, and
some doc/po translation updates (not included in the diff) as well as
strenghthening a build-dep in d/control on the debian/ side (not affecting
Debian because versions are in sync, but it could help if building for
derivatives or in pre-stretch systems).
I attach the diff as git-log with the most important changes, leaving aside the
translation updates and d/control. I think that it's a bit more clear than a
debdiff in this case, but it wouldn't be a problem to provide a debdiff if you
prefer that.
unblock aptitude/0.8.6-1
Cheers.
-- System Information:
Debian Release: 9.0
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1,
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.9.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
commit e46df0b36580be3a1a389f0008b1fc1485b5d963
Author: Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Date: Sun Feb 19 00:22:37 2017 +0100
[cmdline] Better message when there are no deb-src in sources.list (Closes:
#841875)
diff --git a/NEWS b/NEWS
index b9d8250d..e6f241c6 100644
--- a/NEWS
+++ b/NEWS
@@ -1,6 +1,11 @@
[2017-01-xx]
Version 0.8.6 UNRELEASED
+- User visible changes:
+
+ * [cmdline] Better message when there are no deb-src in sources.list
+(Closes: #841875)
+
- Bug fixes:
* Use a more strict mask for comparison of dependency operators, thanks to
diff --git a/src/cmdline/cmdline_action.cc b/src/cmdline/cmdline_action.cc
index 564b8d08..32c01c99 100644
--- a/src/cmdline/cmdline_action.cc
+++ b/src/cmdline/cmdline_action.cc
@@ -1,7 +1,7 @@
// cmdline_action.cc
//
// Copyright 2004 Daniel Burrows
-// Copyright 2015-2016 Manuel A. Fernandez Montecelo
+// Copyright 2015-2017 Manuel A. Fernandez Montecelo
#include "cmdline_action.h"
#include "cmdline_util.h"
@@ -46,6 +46,13 @@ namespace
bool allow_auto,
const std::shared_ptr
_metrics)
{
+// check for deb-src in sources.list or die -- needs to instantiate
+{
+ pkgSrcRecords records(*apt_source_list);
+ aptitude::cmdline::on_apt_errors_print_and_die();
+}
+
+
aptitude::cmdline::source_package sourcepkg =
aptitude::cmdline::find_source_package(pkg,
version_source,
diff --git a/src/cmdline/cmdline_action.h b/src/cmdline/cmdline_action.h
index 758287e6..07f3ab39 100644
--- a/src/cmdline/cmdline_action.h
+++ b/src/cmdline/cmdline_action.h
@@ -1,7 +1,7 @@
// cmdline_action.h -*-c++-*-
//
// Copyright (C) 2004, 2010 Daniel Burrows
-// Copyright (C) 2015-2016 Manuel A. Fernandez Montecelo
+// Copyright (C) 2015-2017 Manuel A. Fernandez Montecelo
//
// This program is free software; you can redistribute it and/or
// modify it under the terms of the GNU General Public License as
commit 0d5495389aabc779539d4d5ff4cd2a5ab6951591
Author: Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Date: Sat Feb 18 22:58:17 2017 +0100
Fix misdetection of auto-installed packages from apt (Closes: #831858,
#841347)
diff --git a/NEWS b/NEWS
index ea4a8a04..b9d8250d 100644
--- a/NEWS
+++ b/NEWS
@@ -19,6 +19,9 @@ Version 0.8.6 UNRELEASED
caused extra problems like classifying the tag in their own subtree due to
the new-line mismatch in the tag name.
+ * Fix misdetection of auto-installed packages from apt
+(Closes: #831858, #841347)
+
- Translation updates:
* ru.po: Russian translation by Lev Lamberov (Closes: #855329)
diff --git a/src/generic/apt/aptcache.cc b/src/generic/apt/aptcache.cc
index 22788f91..5b686480 100644
--- a/src/generic/apt/aptcache.cc
+++ b/src/generic/apt/aptcache.cc
@@ -1,7 +1,7 @@
// aptcache.cc
//
// Copyright 1999-2009, 2011 Daniel Burrows
-// Copyright 2015-2016 Manuel A. Fernandez Montecelo
+// Copyright 2015-2017 Manuel A. Fernandez Montecelo
//
// This program is free software; you can redistribute it and/or modify
// it under the terms of the GNU General Public License as published by
@@ -398,6 +398,13 @@ bool aptitudeDepCache::build_selection_list(OpProgress*
Prog,
pkg_state.remove_reason=(changed_reason)
section.FindI("Remove-Reason", manual);
+ // marked as auto-installed from apt? -- bug #841347
+ //
+ // us
Bug#830997: release.debian.org: Permission to consider dpkg-buildpackage -A bugs as RC
Hi, 2016-07-13 17:21 Santiago Vila: [...] Back in November I started to check and report each and every source package for which "dpkg-buildpackage -A" fails. [...] Making this a release goal would mean that each and every package in stretch (once it's stable) would be suitable to be uploaded in source-only form. I think this feature would be particularly interesting for the security team. Just wanted to thank you for this effort, very nice work. And even if I don't have any authority on the matter, to say that I believe that it's a worthwhile release goal. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#778034: ogre-1.9 needs a library transition for GCC 5
2015-08-13 19:52 GMT+01:00 Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>: > user release.debian@packages.debian.org > usertag 778034 + transition > block 778034 by 790756 > reassign 778034 release.debian.org > stop > > > 2015-08-13 19:16 GMT+01:00 Matthias Klose <d...@debian.org>: >> >> no, please upload to unstable first, then reassign. > > Done and done. According to the build logs, mygui was built against libogre-1.9.0v5, but is marked as "bad" in the transition tracker for all arches. All other rdeps of ogre-1.9 are rebuilt and marked as "good" in the tracker. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#791211: mygui uploaded to unstable (NEW)
2015-09-01 1:42 GMT+01:00 Scott Howard <showard...@gmail.com>: > Hello all, > mygui uploaded to unstable. Since we're changing the package name back > to the original SONAME and appending v5, it's gone in the NEW queue > again. OK, thank you very much! -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#797434: nmu: rdeps of tinyxml (GCC-5 C++ transition)
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Hello, I am trying to help with the ongoing transitions here, specially the GCC-5 C++ one, but I do not have much experience, so please double-check if everything is correct. The packages below have not been rebuilt yet for the new version of tinyxml library with the v5 rename, nor have they been rebuilt recently ( 1 month), so I think that binNMUing this will allow to progress in these transitions: https://release.debian.org/transitions/html/auto-tinyxml.html nmu antigrav_0.0.3-6 . ALL . -m rebuild against libtinyxml2.6.2v5 nmu aseprite_1.0.9+ds-3 . ALL . -m rebuild against libtinyxml2.6.2v5 nmu blobby_1.0-2 . ALL . -m rebuild against libtinyxml2.6.2v5 nmu cbp2make_147+dfsg-1 . ALL . -m rebuild against libtinyxml2.6.2v5 nmu cigi-ccl_3.3.3a+svn818-8 . ALL . -m rebuild against libtinyxml2.6.2v5 nmu crtmpserver_1.0~dfsg-5 . ALL . -m rebuild against libtinyxml2.6.2v5 nmu desmume_0.9.10-2 . ALL . -m rebuild against libtinyxml2.6.2v5 nmu epiphany_0.7.0+0-3 . ALL . -m rebuild against libtinyxml2.6.2v5 nmu garmin-plugin_0.3.23-1+b1 . ALL . -m rebuild against libtinyxml2.6.2v5 nmu gource_0.43-1 . ALL . -m rebuild against libtinyxml2.6.2v5 nmu indigo_1.1.12-1 . ALL . -m rebuild against libtinyxml2.6.2v5 nmu opencity_0.0.6.5stable-2 . ALL . -m rebuild against libtinyxml2.6.2v5 nmu openclonk_6.1-1 . ALL . -m rebuild against libtinyxml2.6.2v5 nmu opencolorio_1.0.9~dfsg0-3+b2 . ALL . -m rebuild against libtinyxml2.6.2v5 nmu openctm_1.0.3+dfsg1-1.1+b1 . ALL . -m rebuild against libtinyxml2.6.2v5 nmu openni_1.5.4.0-13 . ALL . -m rebuild against libtinyxml2.6.2v5 nmu palabos_1.5~r1+repack1-1 . ALL . -m rebuild against libtinyxml2.6.2v5 nmu pokerth_1.1.1-2.2 . ALL . -m rebuild against libtinyxml2.6.2v5 nmu qutecom_2.2.1+dfsg1-5.2+b1 . ALL . -m rebuild against libtinyxml2.6.2v5 nmu sofa-framework_1.0~beta4-9 . ALL . -m rebuild against libtinyxml2.6.2v5 nmu tecnoballz_0.93.1-6 . ALL . -m rebuild against libtinyxml2.6.2v5 nmu trigger-rally_0.6.1-0.1 . ALL . -m rebuild against libtinyxml2.6.2v5 Hope that helps. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com
Bug#790991: transition: cal3d (libcal3d12v5)
2015-08-16 0:43 GMT+01:00 Simon McVittie s...@debian.org: retitle 790991 transition: cal3d (libcal3d12v5) severity 790991 normal reassign 790991 release.debian.org user release.debian@packages.debian.org usertags 790991 + transition forwarded 790991 https://release.debian.org/transitions/html/auto-cal3d.html thanks On Fri, 14 Aug 2015 at 15:54:38 +0100, Manuel A. Fernandez Montecelo wrote: Uploaded changes to experimental. As Julien clarified in https://lists.debian.org/debian-release/2015/08/msg00426.html, I believe this is ready for upload to unstable whenever you want. There are only two reverse dependencies. crystalspace is not in testing and FTBFS anyway, so I think that one can be disregarded. soya has no other C++ build-dependencies, so it is probably ready to be queued up as soon as the updated cal3d gets to unstable: nmu soya_0.15~rc1-10 . ALL . -m 'Rebuild with libcal3d12v5' dw soya_0.15~rc1-10 . ALL . -m 'libcal3d12v5' Thanks, I am a bit behind on my reading of the mailing lists. Uploaded to unstable now. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com
Re: Bug#774890: Is this bug really RC?
2015-01-16 13:38 Andreas Tille: On Fri, Jan 16, 2015 at 12:03:41PM +0100, Axel Beckert wrote: One more thing I'm still curious about: How the fuck do you stumble upon such a bug? :-) I don't expect that Andreas runs piuparts starting with Lenny on a daily business or without reason. I expect that a real-life case (which Andreas B. didn't mention) is hidden behind it and caused him to do that piuparts run. I'd also like to know this. :-) I received a similar bug report for src:ogre (which will not be in Jessie) about a month ago, from Andreas Beckman and the same upgrade paths, so I think that he did in fact do that on a systematic basis, running piuparts over the whole archive and similar. (Nothing bad about it, on the contrary, just adding my two cent^W^W^Wone data point). https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773059 This was observed on the following upgrade paths: lenny (ogre-doc-nonfree) - squeeze - wheezy - jessie -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150116205215.ga27...@reva.itsari.org
Re: more binNMUs for rdeps of OpenSceneGraph? -- was: Re: Bug#768199: marked as done (nmu: simgear_3.0.0-6)
2014-11-07 11:03 GMT+00:00 Jonathan Wiltshire j...@debian.org: On 2014-11-06 21:40, Manuel A. Fernandez Montecelo wrote: (You might want to do the other reverse dependencies as well: while simgear is the only one that we know is affected, it's possible that others are. Can somebody who knows the packages better (i.e. not me) please check and file additional bugs if they are? According to dak the reverse build-dependencies are: choreonoid: libopenscenegraph-dev flightgear: libopenscenegraph-dev ( 3.0.0) libcitygml: libopenscenegraph-dev (= 3.0.1-4~) osgearth: libopenscenegraph-dev (= 3.0.1) openscenegraph (= 3.0.1) ossim: libopenscenegraph-dev qgis: libopenscenegraph-dev simgear: libopenscenegraph-dev ( 3.0.0) I haven't looked in enough detail [yet] to see if those rdepends need binNMUing, and I don't know if there's a clear-cut way to determine that (especially if the issue is because of subtle changes of code which rdepends embed, which could be also the case if they use C++ templates compiled statically into the rdepend binary, and similar artifacts). Maybe it's better to schedule binNMUs for all, to be better safe than sorry? Some packages for Jessie, like choreonoid and osgearth were uploaded in February and April, so they were not even compiled with GCC 4.9 and the latest libstcd++ for example. They could also be affected by other cases of subtle ABI changes in OSG or other dependencies. Not quite true: chorenoid was binNMUd 20 days ago and 43 days ago, so they will not be in the same state as they were at the time of source upload. Hmmm, sorry for the confusion. I looked at the PTS and changelog linked from PTS page, I didn't know that the binNMUs do not appear there. Even with aptitude and apt, changelog doesn't show the NMUs. But most/all of the rdepends have some +b1 or +b2 appended in the version available, so yes, they should be somewhat recent. Looking at the relevant dates though, nothing will have picked up the fix for #765855; scheduling. Don't worry about filing bugs. OK, thanks. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAPQ4b8norCzaLqs2KyTMt0E0TbXrWogRWKBx4VT=a-6tps1...@mail.gmail.com
more binNMUs for rdeps of OpenSceneGraph? -- was: Re: Bug#768199: marked as done (nmu: simgear_3.0.0-6)
Hi, I don't know if Alberto noticed this message, I read it mostly by chance, so copying him. 2014-11-05 22:51 Debian Bug Tracking System: ... From: Rebecca N. Palmer rebecca_pal...@zoho.com To: sub...@bugs.debian.org Date: Wed, 05 Nov 2014 22:10:43 + Subject: nmu: simgear_3.0.0-6 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.2.0 Package: release.debian.org User: release.debian@packages.debian.org Usertags: binnmu Severity: normal X-Debbugs-CC: pkg-fgfs-c...@lists.alioth.debian.org openscenegraph 3.2.1-5 fixed crash bug #765855, but as the fix is in an inline method, a rebuild of simgear is needed to pick it up. nmu simgear_3.0.0-6 . ALL . -m Rebuild to pick up fix for #765855 (You might want to do the other reverse dependencies as well: while simgear is the only one that we know is affected, it's possible that others are. Also, I'm not the maintainer of either package: can anyone ask or is the name binNMU a historical leftover?) From: Jonathan Wiltshire j...@debian.org To: Rebecca N. Palmer rebecca_pal...@zoho.com, 768199-d...@bugs.debian.org Cc: pkg-fgfs-c...@lists.alioth.debian.org Date: Wed, 5 Nov 2014 22:48:28 + Subject: Re: Bug#768199: nmu: simgear_3.0.0-6 User-Agent: Mutt/1.5.23 (2014-03-12) On Wed, Nov 05, 2014 at 10:10:43PM +, Rebecca N. Palmer wrote: openscenegraph 3.2.1-5 fixed crash bug #765855, but as the fix is in an inline method, a rebuild of simgear is needed to pick it up. nmu simgear_3.0.0-6 . ALL . -m Rebuild to pick up fix for #765855 Thanks, scheduling. (You might want to do the other reverse dependencies as well: while simgear is the only one that we know is affected, it's possible that others are. Can somebody who knows the packages better (i.e. not me) please check and file additional bugs if they are? According to dak the reverse build-dependencies are: choreonoid: libopenscenegraph-dev flightgear: libopenscenegraph-dev ( 3.0.0) libcitygml: libopenscenegraph-dev (= 3.0.1-4~) osgearth: libopenscenegraph-dev (= 3.0.1) openscenegraph (= 3.0.1) ossim: libopenscenegraph-dev qgis: libopenscenegraph-dev simgear: libopenscenegraph-dev ( 3.0.0) I haven't looked in enough detail [yet] to see if those rdepends need binNMUing, and I don't know if there's a clear-cut way to determine that (especially if the issue is because of subtle changes of code which rdepends embed, which could be also the case if they use C++ templates compiled statically into the rdepend binary, and similar artifacts). Maybe it's better to schedule binNMUs for all, to be better safe than sorry? Some packages for Jessie, like choreonoid and osgearth were uploaded in February and April, so they were not even compiled with GCC 4.9 and the latest libstcd++ for example. They could also be affected by other cases of subtle ABI changes in OSG or other dependencies. The buildds are mostly idle at this point. The biggest risk with the binNMUs would be if they FTBFS because of changes in compiler or other dependencies since they were last uploaded, I think. But even in that case, it's probably better to discover that sooner rather than later, and have a few months to test the binNMUed packages before the actual release, I guess? Maybe there are other disadvantages about binNMUs that I am missing, so asking again in debian-release@ just in case. If it's OK to go ahead, either Alberto or I would fill in bugs asking for the binNMUs. Cheers. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141106214029.ga6...@reva.itsari.org
Re: Bug#756478: transition: openscenegraph
2014-08-01 09:47 Emilio Pozuelo Monfort: On 30/07/14 10:31, Alberto Luaces Fernández wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Dear Release Team, we are packaging the 3.2.1 stable release of openscenegraph, which is API-compatible with the current version in Debian, so only binNMUs should be needed. Is it not ABI compatible? I'm surprised the SONAME is bumped in a point release. IIRC, they changed ABI between 3.2.0~rc1 (our version in unstable and testing) and 3.2.0. Reverse dependencies are: fgrun flightgear libcitygml osgearth ossim qgis simgear Can you create a transition for us, please? The tracker will be created automatically when the package is in the archive. Please upload to experimental now so the package can go through NEW and the tracker is created. I did that ~10 days ago. Cheers. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140815204920.ga3...@lugh.itsari.org
Bug#729289: transition: openscenegraph
2014-02-03 Rebecca N. Palmer r.pal...@bham.ac.uk: Also, for the future, question to Niels: we know that multiple versions of the same library are discouraged, but maybe it would be useful in this case to accomodate to the pace of different rdeps? That wouldn't be as useful as it might look: openwalnut have long recommended using their own repository (in a VM if necessary) instead of their Debian-main packages (http://www.openwalnut.org/projects/openwalnut/wiki/Getting_OpenWalnut), and all the other problems that were actually due to openscenegraph changes (as opposed to other issues that would be RC bugs whether or not this transition existed) were fixed (at least upstream) months ago. (This starts to be offtopic, so perhaps would be better to stop discussing it in the bug report). I don't understand why this would not be useful with my proposal. Having several versions is supposed to be discouraged, that's why we never tried to implement this, but at least I would be in favour of it. That means that we could have: - 3.3 or 3.4 (when available) for developers using the library directly, and stabilise that version in Debian before we ask rdeps to start to migrate, - 3.2.* for (most) debian rdeps, - and perhaps an older version 3.0.* while other rdepends (more conservative, or less actively maintained) don't migrate. So, if anything, it would help to not make rdeps to move so fast and allow them to stabilise, with larger time-frames to update their build-depends, while still providing the latest and greatest to developers and weeding out some problems before rdeps suffer them. This can only help OpenWalnut to be more stable in Debian, so I don't understand why you say that it would not be useful. If it's simply because nobody uses OpenWalnut, well, in this case it could as well be removed from Debian. Its popcon is very low indeed (not only now, but even more so in the years before OSG was broken). But still, I don't think that low popcon is good reason to remove packages, specially when they are intended to be useful only for a relatively small population. http://qa.debian.org/popcon.php?package=openwalnut Cheers. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/capq4b8mj6jea71lv0qytsxum4ymbqoakgoz4vw0kkbmypwl...@mail.gmail.com
Bug#729289: transition: openscenegraph
2014-02-03 Rebecca N. Palmer r.pal...@bham.ac.uk: The choreonoid maintainer has agreed to my fix. (This starts to be offtopic, so perhaps would be better to stop discussing it in the bug report). Where would you suggest: #718381 (the openwalnut breakage) or a new wishlist bug against openscenegraph? The offtopic part was my question about having several versions at the same time, not the rest. I don't understand why this would not be useful with my proposal. I didn't say it would be useless, just less useful than the high proportion of breakages here might suggest. , and stabilise that version in Debian before we ask rdeps to start to migrate, Use experimental for that? We did that in the past, it's not very useful for feedback because almost nobody uses it, and it does not migrate automatically to unstable or testing until some period so you have to reupload, etc. In general, that's not a substitute for having several versions in unstable or in testing at the same time and be able to switch between them. Cheers. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAPQ4b8merV+5AthZpR9Re7HFhqbumaTp0XCQ+8HpXZoqfPN0=a...@mail.gmail.com
Bug#729289: transition: openscenegraph
2014-02-02 Niels Thykier ni...@thykier.net: On 2014-02-01 14:11, Rebecca N. Palmer wrote: The state of openscenegraph itself isn't the problem here: what we're waiting for is for simgear to clear NEW and for Release Team to give official permission (britney hint??) to ignore openwalnut for now. Actually both of those things are FTP master decisions. If openwalnut had been in testing, then that part would need both FTP masters and the Release Team - but since it is not, then we just need the FTP masters approval for getting openscenegraph decrufted at the price of breaking openwalnut (even further). I can ask the FTP masters to process simgear - decrufting openscenegraph will have to wait until we have fixed all the packages that we can. There is the separate question of whether you want an ~rc in an Ubuntu LTS (14.04 freezes 20 Feb), but they finished their transition to 3.2.0rc months ago (by removing openwalnut) and will sync from experimental if you ask them to, so that isn't tied to what we do in Debian. Based on Manuel's mail (not quoted here), I think I would prefer if we transitioned to openscenegraph ABI 99 rather than 100. In my eyes, it makes the whole thing simpler and means we can start working immediately - especially considering that our best guess on a release date for the new version is more than a week or two away (Manuel suggested March or later). Actually, I meant to say that we (or at least I) don't have any confidence in the accuracy of our best guesses for the date when 3.2.1 final will be available (meaning: I don't have much confidence in upstream's predicitons, or their assurance to not change ABI again for 3.2.1 final). Because the estimations from upstream have been any time now for months (repeated every now and then), but with a delay of more than 3 months since the initial estimate. But it can also be released in the next days or weeks... nothing prevents that, AFAIK. Perhaps Alberto or Rebecca (who follow upstream mailing lists) have better guesses about the current state of mind of upstream. So we finally gave up on waiting and fixed the current version in Debian unstable in mid January without waiting any longer, trying not to continue causing disruption in Debian. From my part, and I think Alberto's, any solution minimising problems for the rest of Debian will be fine. Given that any newer upstream release (even 3.2.0 final) will have to go through the NEW queue (ABI/soname changes), even if they release tomorrow it will take a while to get to unstable anyway; and then there's the round of binNMUs and NMUs. So for the sake of rdeps, we thought that stabilising with ABI 99 is a good idea, or else we might continue in the same situation for months. Also, for the future, question to Niels: we know that multiple versions of the same library are discouraged, but maybe it would be useful in this case to accomodate to the pace of different rdeps? This library doesn't exist in Debian only (or perhaps even mainly) because the rdeps in Debian, but because of the library itself, and many people use it independently of other packages installed. That's why it is desirable to have the latest versions quickly as well. Cheers. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAPQ4b8=nn_9_oueyhjmswckgbt6fjhbepttnzsgnltwt3jq...@mail.gmail.com
Bug#729289: whatever you want to call this: openscenegraph
2014-01-31 Markus Wanner mar...@bluegap.ch: On 01/31/2014 07:28 PM, Niels Thykier wrote: On the topic of 99-100, do you know if that will happen any time soon? I am wondering whether we should go for finishing the 80-99 and do a separate 99-100 or wait and jump directly from 80-100. If 100 is coming soon, it is probably easiest to do 80-100 (will save us a couple of rebuilds and we waiting for other things right now anyway). On the other hand, I would hate for this transition to drag on waiting for a new version that isn't happening while blocking other packages from reaching testing. IIUC release 3.2.0 (as opposed to the rc) already brings SOVERSION 100. So we could release that and transition to 100 right away. What Markus says is right. What happened was that they did some important/nasty code changes just before the the ~rc1, which we/I didn't relalise that it would be bad (because upstream didn't expect any major problems). But adapting other packages to it was not as easy/smooth as upstream expected. Then they changed 99-100 between version 3.2.0~rc1 (current package in Debian) and the final 3.2.0, so updating Debian would cause again a round of rebuilds and maybe more source changes; and while pondering whether to upgrade the package in Debian to the final upstream version, they released 3.2.1~rc1 very shortly afterwards, planning to release 3.2.1 within the same month. But that was in October, with expectations every now and then that the release would be imminent, but it didn't happen. So we wanted to jump from 3.2.0~rc1 with SOVERSION 99 to 3.2.1 final with SOVERSION unknown), to avoid the problems that Niels mentions (despite what Markus said later, I thought that it can be higher than 100 before 3.2.1 final). (There were other problems and the package was unbuildable for quite some time, mostly my fault, but in truth related with other pressing issues in my Debian duties and due to expecting to have the 3.2.1 upstream released and fixing everything together without more disturbances to rdeps... which didn't happen, so we recently decided to not wait any longer and fix 3.2.0~rc1). Also note that release 3.2.1 is due as well (for quite some time now, though. RC2 has been released, recently). However, according to their website [1], it should be binary compatible. (And their current 3.2 branch still has a SOVERSION of 100.) So going straight through to 100 seems reasonable to me. Seeing that back in summer we took a similar decision based on similar premises, which later were not fulfilled and led to the situation that we have now, I am not sure that we should jump to 3.2.1, or even that it's going to be released before March or April. But I am open to any suggestion really, I just want to avoid more problems for rdeps. Cheers. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/capq4b8mnkrwi4njgcel+_eut5nx27wa56cusfibjttgbqyt...@mail.gmail.com
Bug#729289: transition: openscenegraph
2014/1/23 Manuel A. Fernandez Montecelo manuel.montez...@gmail.com: 2014/1/22 Rebecca N. Palmer r.pal...@bham.ac.uk: choreonoid and ossim turned out to also FTBFS (for non-openscenegraph-related reasons); I have posted a patch for choreonoid (#735891), and suggested that ossim (#735814) move to the already-fixed version in the UbuntuGIS PPA. chorenoid can be NMUed, if that works, or solved by asking FTP to remove from mipsel. For OSSIM yes, it does not look good, it would probably need a major upgrade (the last upload was almost 2 years ago) or at least fix the immediate problem with libtiff5 plus other problems that might appear (I guess that it would affecting the transition libtiff5 as well). Or remove it completely, I don't know if that would be a good idea or likely to get people to agree. I was talking yesterday with Markus Wanner and I think that he can either update OSSIM or fix it to fix the building problems, so if this happens it will clear the way quite a bit. Cheers. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAPQ4b8nF-1=ST=wwfsragvkubmbdpinmupaobmhar8zv3ww...@mail.gmail.com
Bug#729289: transition: openscenegraph
After asking in #debian-ftp... 2014/1/22 Rebecca N. Palmer r.pal...@bham.ac.uk: choreonoid and ossim turned out to also FTBFS (for non-openscenegraph-related reasons); I have posted a patch for choreonoid (#735891), and suggested that ossim (#735814) move to the already-fixed version in the UbuntuGIS PPA. chorenoid can be NMUed, if that works, or solved by asking FTP to remove from mipsel. For OSSIM yes, it does not look good, it would probably need a major upgrade (the last upload was almost 2 years ago) or at least fix the immediate problem with libtiff5 plus other problems that might appear (I guess that it would affecting the transition libtiff5 as well). Or remove it completely, I don't know if that would be a good idea or likely to get people to agree. this no longer blocks anything else or needs to be handled as a transition. britney still thinks it does: out of date on i386: libopenscenegraph80 (from 3.0.1-4.1). Given that libopenscenegraph80 is uninstallable (it depends on the no-longer-existing libavcodec53/libavformat53/libavutil51), keeping it around doesn't actually help its reverse dependencies; how should this be dealt with? (request its removal? request that openscenegraph be forced to testing anyway?) Packages from chorenoid on mipsel and OSSIM elsewhere depend on libopenscenegraph80 which is no longer built. I imagined that by removing OSG and rev-deps from testing, this would not prevent OSG to migrate to testing... but it does. Asking for removal of libopenscenegraph80 alone does not help as long as there are rev-deps... I asked for removal of src:ogre many months ago and still not done because Ember depends on it, even if it cannot build from source for almost a year. Cheers. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/capq4b8nvivqbczxzi6kcxewp5gersbhhcvnvo-g6fug_fnc...@mail.gmail.com
Bug#729289: 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-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/capq4b8mpfa3bygb-1rtnkjkrznr++ised_zeujxln0xex8c...@mail.gmail.com
Bug#729289: 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-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/capq4b8mvzgzwgfc4_o2jizjrf+mog+lbuna9x_gb+gzwf1z...@mail.gmail.com
Bug#729289: 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-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/capq4b8noqzmkruqqlp5gsvoqcy_ybjmgp2gbrgdqzxhy7tq...@mail.gmail.com
Bug#699109: unblock (pre-approval): initramfs-tools-tcos/0.89.91
2013/1/27 Julien Cristau jcris...@debian.org: On Sun, Jan 27, 2013 at 17:42:48 +, Manuel A. Fernandez Montecelo wrote: Could Release Team please say if the changes proposed in #694870 to fix an RC bug are OK to go? Please include an actual diff in this bug instead of a pointer to $somewhere_else. Attached. According to the discussion in that bug report, the patch does need to be so big to fix three separate issues, and without the fixes it seems that the software will not be functional. Cheers. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com bd77023afadfe96a0c6ab86343b02b695567439f.patch Description: Binary data
Bug#699109: unblock (pre-approval): initramfs-tools-tcos/0.89.91
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-CC: mariodeb...@gmail.com Hi, Could Release Team please say if the changes proposed in #694870 to fix an RC bug are OK to go? Cheers. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAPQ4b8mOSnLxagTF4yC7_5=hcn-zqtlnvzyos58go2ttdmg...@mail.gmail.com
Freeze exception request to openscenegraph 3.0.1-4 for wheezy
Hi, (Please CC pkg-osg-devel@ when replying). We're preparing a fix for a bug in openscenegraph (see attached file). I am not sure if the bug should be considered release critical, but at least it's an important drawback for people using pkg-config along with the library. There are also some other fixes, including enabling hardened builds. The changes are not very intrusive, I think, but we're not very sure about dh compat level 7 - 9. Can you please comment/advise? Cheers. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com debdiff_openscenegraph-3.0.1-3_to_-4.diff Description: Binary data
Re: Request unblock sdl-stretch/0.3.1-3
2012/10/4 Philipp Kern pk...@debian.org: For the record: I just added an unblock hint for sdl-stretch/0.3.1-3. Thank you very much. Cheers. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/capq4b8kqmybdkvbmvzt7_m+zocpka2erx+c80rbdobrtng+...@mail.gmail.com
Re: Request unblock sdl-stretch/0.3.1-3
2012/7/28, Philipp Kern pk...@debian.org:
On Sun, Jul 08, 2012 at 11:58:28AM +0100, Manuel A. Fernandez Montecelo
wrote:
I would like to ask an unblock to sdl-stretch/0.3.1-3.
There's an unblock already for sdl-stretch/0.3.1-2 because it was in
unstable before the freeze, but -2 failed to build in kfreebsd-i386
and thus it never migrated to testing:
Yep, hence the unblock for -2 does not matter. There are changes in
debian/rules
that are not mentioned in the changelog (like the DEB_CFLAGS_MAINT_APPEND
and
DEB_LDFLAGS_MAINT_APPEND bits). Please revert those. You also introduced a
whitespace issue in debian/rules.
These changes that you mention, were introduced the 26th of April for
0.3.1-2, well before the release, without any bug report being
submitted since then. This is what it's already authorised to migrate
in the unblock.
The only changes introduced are the ones about architecture, 2 lines,
and the changelog. In the case that I didn't attach the diff
recently, I do it now, as generated by:
debdiff ../*/sdl-stretch_0.3.1-[23]*.dsc /tmp/sdl-stretch_-2_to_-3.diff
If you don't feel comfortable about authorising -2 either, that's
another question. It's been working apparently fine for 3+ months
now, without any bug report (then again it's not much used, so if
people find bugs maybe they're just ignoring it).
I've been working and spending time with this package with the hope
that the best possible version goes into unstable. It was only built
in i386 arches, which are mostly obsolete in mainstream hardware,
since nobody had bothered to update this package in the past few
Debian releases since 2005 when amd64 was not even an accepted
architecture.
I think that reversing these changes is not a good idea, for reasons
explained in the changelog and these bugs reports, I won't repeat
myself. So if you prefer to just remove the unblock, or the package
altogether for the next stable, I think that I prefer that solution to
producing a package that will get a FTBFS shortly after stable is
released.
Cheers.
--
Manuel A. Fernandez Montecelo manuel.montez...@gmail.com
diff -Nru sdl-stretch-0.3.1/debian/changelog sdl-stretch-0.3.1/debian/changelog
--- sdl-stretch-0.3.1/debian/changelog 2012-04-26 15:51:26.0 +0100
+++ sdl-stretch-0.3.1/debian/changelog 2012-07-04 20:25:34.0 +0100
@@ -1,3 +1,22 @@
+sdl-stretch (0.3.1-3) unstable; urgency=low
+
+ * Change Architecture: any-amd64 any-i386 for both binary packages.
+
+This package is a bit special because it contains optimised routines in
+assembler for some architectures, so even if it can be built successfully in
+others, it doesn't really make sense to provide the package. According to
+upstream, current models of both i386 and amd64 are supported, and while
+it's desired to have support in other platforms (e.g. ARM), it's not there
+yet.
+
+Before 0.3.1-1, debian/control was set only to build on i386; and in 0.3.1-1
+it was set to any, but the file
+https://buildd.debian.org/quinn-diff/sid/Packages-arch-specific restricted
+the architectures effectively to i386 kfreebsd-i386 hurd-i386 (see
+#680275).
+
+ -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com Wed, 04 Jul 2012 20:12:03 +0100
+
sdl-stretch (0.3.1-2) unstable; urgency=low
* Bump Standards-Version to 3.9.3 (no changes needed)
diff -Nru sdl-stretch-0.3.1/debian/control sdl-stretch-0.3.1/debian/control
--- sdl-stretch-0.3.1/debian/control 2012-04-26 15:51:35.0 +0100
+++ sdl-stretch-0.3.1/debian/control 2012-07-04 20:07:19.0 +0100
@@ -17,7 +17,7 @@
Homepage: http://sdl-stretch.sourceforge.net
Package: libsdl-stretch-0-3
-Architecture: any
+Architecture: any-amd64 any-i386
Multi-Arch: same
Pre-Depends: ${misc:Pre-Depends}
Depends: ${shlibs:Depends},
@@ -33,7 +33,7 @@
Package: libsdl-stretch-dev
Section: libdevel
-Architecture: any
+Architecture: any-amd64 any-i386
Depends: ${misc:Depends},
libsdl-stretch-0-3 (= ${binary:Version}),
libsdl1.2-dev(= 1.2.14~)
Re: Request unblock sdl-stretch/0.3.1-3
2012/7/28 Philipp Kern pk...@debian.org: On Sat, Jul 28, 2012 at 02:02:47PM +0100, Manuel A. Fernandez Montecelo wrote: These changes that you mention, were introduced the 26th of April for 0.3.1-2, well before the release, without any bug report being submitted since then. This is what it's already authorised to migrate in the unblock. As said we don't care. The package was unable to migrate by itself so that exception is void. The package didn't migrate to testing not because of any problem of the package itself, nor the changes in -2, or while building it or bug reports, but because of a row in Package-arch-specific set in 2005 that allowed it only to be built for i386. In 2009 and 2011 the package was updated (incl. 2011, when the arch-restriction in debian/control was removed), but the restriction in that P-a-s file remained intact. So the package wasn't ever built *by buildd daemons* in amd64 arches (or any other non-386). But since it happens that we uploaders have amd64 machines, the package was actually provided in binary form for amd64 in the Debian repositories. It was never part of mips, armel or any other architecture, not even kfreebsd-amd64 where it's now built: === sdl-stretch: (you co-maintain it) = Missing build(s) on amd64 armel ia64 kfreebsd-i386 mips This might need manual action from your side. See https://buildd.debian.org/status/package.php?p=sdl-stretch = No migration to testing for 64 days. See http://release.debian.org/migration/testing.pl?package=sdl-stretch I updated -2 in April also without realising that, and about the freeze as per the notice above, I realized that this package was not being migrated to testing (-2 hadn't make it in 3 months) because of that ancient restriction in Package-arch-specific, etc. Why did -1 migrate but -2 didn't? I really don't know, but it was not due to a bug report or inherent problem. While trying to fix that and requesting removal from Package-arch-specific, I *was asked* to create -3 because a developer called Philipp Kern set it as a pre-requisite for him to remove the restriction on packages-arch-architecture [1]. And that's where we are now, otherwise the package would have already been migrated with -2, and this unblock would be a non-issue. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=680275 I don't see how those ramblings relate to the two lines I objected to. They don't explain them, they just say that there was no bug report (yet). *Why* does one need to set -pipe -Wall, *why* --as-needed (whose prior absence might cause rdepends to rely on linkage to be present), *why* --no-undefined. But then I see now that it hasn't got any rdepends at all. The changes in -2 were mostly harmless, whitespace + debhelper/policy depends updates + descriptions, and only these extra BUILD options which didn't cause any problem in buildds, nor any bug reports, same in Ubuntu (they already have -3 since a few weeks, also no bugs). The same options are used in other SDL packages (so they are there for consistency). --no-undefined is present already in the current version of sdl-mixer1.2 (~17k popcon, 15% of Debian systems) before the renewed SDL-team took over; and in the testing/unstable version sdl-ttf2.0, sdl-sound1.2, sdl-net1.2 since 8 months ago. --as-needed in most SDL modules. -pipe -Wall are pet peeves of mine, present in almost all of the packages that I maintain in Debian. I am not saying that they *have* to be there, but that now that they are there, most of them I deem them innocuous and want them to be there in the future, some of the more dangerous LDFLAGS don't seem to cause problem (and they are supposed to bring hardening benefits, which incidentally it's a release goal, even if --no-undefined is not included), and so I don't want to spend time removing them from sdl-stretch. So I'm not keen on the idea of spending more time changing back things that are IMO mostly inoccuous and will be introduced again ASAP, with no evidence so far that cause problems here or in Ubuntu, when if these do indeed cause an option they are already identified and can be promptly corrected in a new upload *if they really cause harm*. Apart from that, I've been waiting most of this month for this issue to be solved, now I am embarked in other tasks. So I respect your decision as release manager/helper and agree if you don't want to approve -3 or want to remove sdl-stretch altogether, but I'm really not planning in going ahead with the changes that you request. We've all been spending more time on this that this package really deserves. Maybe some other people in SDL team will, although I know that at least some of them are on holidays and offline for a few days/weeks. Also I do not see how reverting those changes make that package FTBFS shortly after stable is released. Having -1 without changes in -3, and now that the restriction in P-a-s files is removed, will make that a binary rebuild
Re: Request unblock sdl-stretch/0.3.1-3
Just to be clear... 2012/7/28 Manuel A. Fernandez Montecelo manuel.montez...@gmail.com: We've all been spending more time on this that this package really deserves. I'm also including you (Philipp) in this group, for the P-a-s file and these e-mails; as well as other debian-release folks who looked at it. So please, just decide if -3 will go as it is, or not at all. Cheers. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAPQ4b8k37n3tEFFor8=0e_3jfeackggbpk9siugule-jwyu...@mail.gmail.com
Bug#681110: unblock: sdl-stretch/0.3.1-3
2012/7/17 Julien Cristau jcris...@debian.org:
There's an unblock already for sdl-stretch/0.3.1-2 because it was in
unstable before the freeze, but -2 failed to build in kfreebsd-i386
and thus it never migrated to testing:
https://buildd.debian.org/status/logs.php?pkg=sdl-stretcharch=kfreebsd-i386
I produced -3 and asked the package to be removed from
Packages-arch-specific (see #680275) so it would build in
kfreebsd-amd64 and amd64 [1], but we were asked to restrict the
architectures ourselves first (any-amd64 any-386) in a new
revision/upload of the package before granting the removal.
The package doesn't have rdepends, so this unblock shoudln't cause much
impact:
The package doesn't have rdepends, so the lack of an unblock shouldn't
cause much impact. Are there users requesting this package on kbsd64,
or another reason why this is particularly important to add now?
The situation is a bit messy, I hope that I can explain myself in the
next few paragraphs.
I figured out that if -2 was to be allowed, -3 could be as well; and
it's not only kfreebsd-amd64 but amd64 itself, which is probably the
most important architecture by now.
The thing is, sdl-stretch is a relatively unimportant package in the
SDL-team realm, so we attended other packages first (most were
abandoned by the end of 2011). Recently I went to look why
sdl-stretch wasn't migrating, and I discovered that it had a
restriction in packages-arch-specific that was restricting it for
386 only. I checked with upstream and the package is actually
amd64-capable (it contains assembler routines, so it's not available
for any actitectures), but it was restricted to 386 in Debian since
2005 or so.
The amd64 package is actually present because we built it with
pbuilder in amd64 arch and uploaded it, but if the package was to be
rebuilt when the P-A-S restriction was in place, it wouldn't build in
amd64 in the buildds.
OTOH, -2 was not restricted in debian/control to amd64 and i386
architectures (which is the thing that I fixed in -3), so if it's
rebuilt now, it will try to be built in all architectures, and in some
of them it will probably fail, thus causing a FTBFS later in the
freeze period or beyond (once released).
So I think that the best thing to do is to allow -3 to go in, the only
actual change it's the restriction on architectures (see debdiff
attached), and it was requested before buildd team accepted to remove
it from the P-A-S file:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=680275
Cheers.
--
Manuel A. Fernandez Montecelo manuel.montez...@gmail.com
diff -Nru sdl-stretch-0.3.1/debian/changelog sdl-stretch-0.3.1/debian/changelog
--- sdl-stretch-0.3.1/debian/changelog 2012-04-26 15:51:26.0 +0100
+++ sdl-stretch-0.3.1/debian/changelog 2012-07-04 20:25:34.0 +0100
@@ -1,3 +1,22 @@
+sdl-stretch (0.3.1-3) unstable; urgency=low
+
+ * Change Architecture: any-amd64 any-i386 for both binary packages.
+
+This package is a bit special because it contains optimised routines in
+assembler for some architectures, so even if it can be built successfully
in
+others, it doesn't really make sense to provide the package. According to
+upstream, current models of both i386 and amd64 are supported, and while
+it's desired to have support in other platforms (e.g. ARM), it's not there
+yet.
+
+Before 0.3.1-1, debian/control was set only to build on i386; and in
0.3.1-1
+it was set to any, but the file
+https://buildd.debian.org/quinn-diff/sid/Packages-arch-specific restricted
+the architectures effectively to i386 kfreebsd-i386 hurd-i386 (see
+#680275).
+
+ -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com Wed, 04 Jul
2012 20:12:03 +0100
+
sdl-stretch (0.3.1-2) unstable; urgency=low
* Bump Standards-Version to 3.9.3 (no changes needed)
diff -Nru sdl-stretch-0.3.1/debian/control sdl-stretch-0.3.1/debian/control
--- sdl-stretch-0.3.1/debian/control2012-04-26 15:51:35.0 +0100
+++ sdl-stretch-0.3.1/debian/control2012-07-04 20:07:19.0 +0100
@@ -17,7 +17,7 @@
Homepage: http://sdl-stretch.sourceforge.net
Package: libsdl-stretch-0-3
-Architecture: any
+Architecture: any-amd64 any-i386
Multi-Arch: same
Pre-Depends: ${misc:Pre-Depends}
Depends: ${shlibs:Depends},
@@ -33,7 +33,7 @@
Package: libsdl-stretch-dev
Section: libdevel
-Architecture: any
+Architecture: any-amd64 any-i386
Depends: ${misc:Depends},
libsdl-stretch-0-3 (= ${binary:Version}),
libsdl1.2-dev(= 1.2.14~)
Bug#681110: unblock: sdl-stretch/0.3.1-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock I would like to ask an unblock to sdl-stretch/0.3.1-3 There's an unblock already for sdl-stretch/0.3.1-2 because it was in unstable before the freeze, but -2 failed to build in kfreebsd-i386 and thus it never migrated to testing: https://buildd.debian.org/status/logs.php?pkg=sdl-stretcharch=kfreebsd-i386 I produced -3 and asked the package to be removed from Packages-arch-specific (see #680275) so it would build in kfreebsd-amd64 and amd64 [1], but we were asked to restrict the architectures ourselves first (any-amd64 any-386) in a new revision/upload of the package before granting the removal. The package doesn't have rdepends, so this unblock shoudln't cause much impact: $ apt-cache rdepends libsdl-stretch-dev libsdl-stretch-dev Reverse Depends: [no output, no rdepdends] $ apt-cache rdepends libsdl-stretch-0-3 libsdl-stretch-0-3 Reverse Depends: libsdl-stretch-dev Cheers. [1] The restriction to i386 comes from 2005 (see URL below); upstream was subsequently updated to support amd64 as well but not updated until recently, when new blood in SDL team took over. http://packages.debian.org/changelogs/pool/main/s/sdl-stretch/current/changelog#version0.2.3-4 unblock sdl-stretch/0.3.1-3 -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120710173346.4309.16644.report...@lugh.itsari.org
Re: Would a new upstream release for Flare game with little dependencies/impact be granted?
2012/7/8 Cyril Brulebois k...@debian.org: given the freeze has started already, and there's nothing like a stable release for the 0.16 series, it looks to me like the best way to go for your package is backports to wheezy-backports once wheezy is released. OK, thanks for the tip! -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAPQ4b8kAH-HCH-kF=jE8VLQPEV-Znh2=8ky_qvzx9t7+atv...@mail.gmail.com
Request unblock sdl-stretch/0.3.1-3
Hello, I would like to ask an unblock to sdl-stretch/0.3.1-3. There's an unblock already for sdl-stretch/0.3.1-2 because it was in unstable before the freeze, but -2 failed to build in kfreebsd-i386 and thus it never migrated to testing: https://buildd.debian.org/status/logs.php?pkg=sdl-stretcharch=kfreebsd-i386 I produced -3 and asked the package to be removed from Packages-arch-specific (see #680275) so it would build in kfreebsd-amd64 and amd64 [1], but we were asked to restrict the architectures ourselves first (any-amd64 any-386) in a new revision/upload of the package before granting the removal. The package doesn't have rdepends, so this unblock shoudln't cause much impact: $ apt-cache rdepends libsdl-stretch-dev libsdl-stretch-dev Reverse Depends: [no output, no rdepdends] $ apt-cache rdepends libsdl-stretch-0-3 libsdl-stretch-0-3 Reverse Depends: libsdl-stretch-dev Cheers. [1] The restriction to i386 comes from 2005 (see URL below); upstream was subsequently updated to support amd64 as well but not updated until recently, when new blood in SDL team took over. http://packages.debian.org/changelogs/pool/main/s/sdl-stretch/current/changelog#version0.2.3-4 -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAPQ4b8=XuDaq3EiviajG6Pz=rsxzywt3vf2calcyqehkwqx...@mail.gmail.com
Would a new upstream release for Flare game with little dependencies/impact be granted?
Hello, The game flare is based on SDL libraries only and with no dependencies outside that. The first release of the game was in 2010. The initial version in Debian was 0.14 in october 2011, followed by 0.15.1 by the turn of the year. It quickly reached (and stabilised) on popcon of ~100 even without being present in a stable release. Upstream released 0.16 yesterday [1], it might be a bit premature to try to get into unstable though, since there might be bug-fix releases soon. And then there's the problem of having to keep the same version in unstable and testing because of the Debian bug fixes for wheezy. [1] http://clintbellanger.net/rpg/blog/20120707 IMO the best things about the game are that it's relatively low on resources and dependencies (so highly available across arches and old computers or small devices), yet quite polished and focused on delivering a good experience. It's picking up a lot of momentum with quite a few contributors. Even if Wheezy is released within this year, 0.15 would be quite behind the current state of the game. So the question is, would it be possible to wait a bit and let 0.16 series to stabilise and package it for Wheezy; or is this completely ruled out? Cheers. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/capq4b8nffhz84doe_edoa5_lrocvphjxm8gdeowckpoykmy...@mail.gmail.com
Bug#680092: nmu: ogre_1.7.4-5
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Please binNMU ogre 1.7.4-5 in mipsel. ogre-1.8 is very similar, has been rebuilt a couple of days ago without problems. Neither 1.7 nor 1.8 fail in any other architectures, so I believe that this is a transient error particular to mipsel, related with Python support or dependencies. The package is largish and I think that rebuilding only in mipsel is the solution putting less strain in all of the buildd infrastructure, especially in these times with the frenzy of the freeze. If some other solution is preferrable, please advise. nmu ogre_1.7.4-5 . mipsel . -m 'Rebuild in mipsel' Regards. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAPQ4b8n7pyqLZJNWcXS=o6w-aivy+yda+ce7ziwksr1tssv...@mail.gmail.com
Bug#680093: nmu: k3d_0.8.0.2-18
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Please binNMU k3d 0.8.0.2-18 in mipsel. I believe that this is a transient error particular to mipsel, related with Python support or dependencies: it's the same situation explained for my nmu request about OGRE (#680092), same Python error only happening in mipsel, etc. The package is largish and I think that rebuilding only in mipsel is the solution putting less strain in all of the buildd infrastructure, especially in these times with the frenzy of the freeze. If some other solution is preferrable, please advise. nmu k3d_0.8.0.2-18 . mipsel . -m 'Rebuild in mipsel' Regards. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAPQ4b8nycox2QTe1Mco8L+S1T9vti6VFN0C6vOkUx-MZxz=m...@mail.gmail.com
Re: freeze exception for gcc-4.5 (i386, amd64 only)
Hello, Sorry for cross-posting if not appropriate, I'm just preserving the e-mail headers. On Friday 20 August 2010 11:34:51 Neil McGovern wrote: On Wed, Aug 18, 2010 at 05:17:32PM +0200, Matthias Klose wrote: I'm not sure there are any in the original, plugins and a greater optimisation level certainly aren't things which will solve specific problems. Could you highlight them for me? Having these features available for developers, and having not to wait two years until these appear in a stable release is worth the update. Exposing a new compiler version to upstream developers helps reducing the delta between upstream and debian packages. Yes I think this is worth having it in squeeze. I don't think that stable is the place for doing active development. I realize that being a Release Manager, part of the task assigned is deciding precisely things like this, which is appropriate for which distribution (at least for the stable). However, I don't think that it makes much sense to say that stable is not a place for doing active development. In places in which I work or worked in the past, using anything other than stable (Debian, Scientific Linux, whatever) is not an option, and so the development is done with whatever tools happen to be there. Is it a better solution to force these people to use the package from the next testing or backports, if they need it for any reason? I can agree that by Debian standards using 4.5 to compile the whole archive with 4.5 might be considered risky (at least for some archs), but I fail to see what's the harm of shipping 4.5 as an *option*. Given that there doesn't seem to be any compelling reason for gcc4.5 in squeeze, I'm afraid it's not going to make it for this release. The argument can be reversed. There is no compelling reason for a developer to use 4.4 series when 4.5 was released 4 months ago (which will be probably more than 6 to a year by the time the release happens), if there is not a specific problem with the new version. Fast forward 1.5 to 2 years, when Squeeze is about to be EOL'd. Why would you use software 3 years old, with maintainance releases maybe stopped since long, with several major versions released since then? Cheers. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201008201226.29919.manuel.montez...@gmail.com
Re: Please don't ship current Aqsis and K3D versions in Squeeze
Hello, The packages are finally updated in testing. You can remove the freeze exception if they are already there. Thanks, Release Team! Cheers. On Sunday 08 August 2010 14:21:57 Manuel A. Fernandez Montecelo wrote: Hi there, On Saturday 07 August 2010 20:12:27 David Martínez Moreno wrote: I agree with Philip, that's the fastest way to proceed. I've already filed bugs for both packages. I think we can fix the problems later, but right now I agree with Manuel that the kfreebsd and hppa are not that important to block these versions from migrating into testing. Thank you very much for your care, OK, I received the notifications about the removal of the packages (thanks for filing them yourself, David), although it's not already reflected in the PTS web site. Thanks to you too, Philipp. Cheers. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201008131249.10573.manuel.montez...@gmail.com
Re: Please don't ship current Aqsis and K3D versions in Squeeze
Hi there, On Saturday 07 August 2010 20:12:27 David Martínez Moreno wrote: I agree with Philip, that's the fastest way to proceed. I've already filed bugs for both packages. I think we can fix the problems later, but right now I agree with Manuel that the kfreebsd and hppa are not that important to block these versions from migrating into testing. Thank you very much for your care, OK, I received the notifications about the removal of the packages (thanks for filing them yourself, David), although it's not already reflected in the PTS web site. Thanks to you too, Philipp. Cheers. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201008081421.58136.manuel.montez...@gmail.com
Please don't ship current Aqsis and K3D versions in Squeeze
Hello, (I'm not subscribed to the list, please CC). Following the announcement about the freeze, this e-mail is a request to either ship in Squeeze the newer versions of the Aqsis [1] (an off-line software renderer, unlike OpenGL or the like which do it in real time and on a window on the screen) and K3D [2] (a 3D modeller, akin to Blender) packages available in unstable, or drop them from the next stable release. I send copy of this mail to David Martínez Moreno (maintainer), although it was me who updated the packages in unstable, maybe he has another idea. In this case probably his decision should prevail. Aqsis = Aqsis's version in stable and testing is 1.2, and 1.6 in unstable that I created recently. 1.6 is almost 1 year old and 1.2 more than 3 years old (which will probably be 1+ years and 4- years respectively, by the time Squeeze is actually released) [3]. In between them there was 1.4, but this version was never uploaded to unstable. The reason why this package wasn't migrated to testing yet it's because it won't build on HPPA (it doesn't have any RC bugs or any other problem, AFAICT). I asked for an account in HPPA machines and verified that for HPPA, there's some kind of infinite loop when compiling some shaders provided by the package. The shaders are compiled by one of the binaries shipped with the package (aqsl), which uses flex heavily. I contacted upstream and they are not interested in it not building in HPPA architecture and suggest that it might be flex's fault. I don't have time to look deeper into the problem for a few weeks/months nor intimate knowledge of the code, so maybe I can't even provide a reasonable fix even if I try. Anyhow, the thing is that probably nobody ever ran Aqsis on HPPA, the more professional users of Aqsis would surely use top-notch hardware and they won't bother with versions 4 years old. More informal users would probably use more common desktop machines at home, not HPPA. So from my point of view, it doesn't make any sense to ship this software with a version about ~4 years old just because it doesn't build on HPPA machines. K3D === K3D's case is very similar, the main difference is that 0.6.7 version (the one in stable an testing) is even older than Aqsis', and the current 0.8.0.2 in unstable was released about 1 month ago. K3D is to be used in the desktop, and probably nobody in their sane minds are going to use a version almost 4 years old or in HPPA. Apart from a FTBFS with gcc-4.5 (#565008) and another known problem with missing Breaks (#588604) it also won't build on HPPA (#588923, this might be fixable adding another flag to the compiler), and it doesn't build on kfreebsd-* and hurd-* because of the missing package libinotify-dev. I tried to use the conditional dependency [linux-any] for this package (K3D *can* work without this library, only that it has the related features disabled); but pbuilder doesn't support it and I was told that the daemons on buildd farm don't support it either, although there were people trying to fix it. Maybe there's a way to get this working now. Conclusion == Aqsis is probably not going to be fixed to compile in HPPA (in time to Squeeze anyway), K3D might be if I have enough free time and you think that it's a good idea to give it a try. But if the packages are not going to be migrated for whatever reason and Squeeze is going to be released with the old versions, I think that it's better to remove them completely. What's your opinion about this, David and Release Managers? Cheers. [1] http://packages.qa.debian.org/a/aqsis.html [2] http://packages.qa.debian.org/k/k3d.html [3] http://sourceforge.net/projects/aqsis/files/ [4] http://sourceforge.net/projects/k3d/files/ -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201008061726.36975.manuel.montez...@gmail.com
Re: Please don't ship current Aqsis and K3D versions in Squeeze
Hello Philipp, *, On Friday 06 August 2010 19:17:59 Philipp Kern wrote: Anyhow, the thing is that probably nobody ever ran Aqsis on HPPA, the more professional users of Aqsis would surely use top-notch hardware and they won't bother with versions 4 years old. More informal users would probably use more common desktop machines at home, not HPPA. So from my point of view, it doesn't make any sense to ship this software with a version about ~4 years old just because it doesn't build on HPPA machines. please file a partial binary removal request against ftp.debian.org to remove the hppa binary and do no further uploads until the package migrated to testing. That should solve the issue of the package not going in. OK, that sounds like a good plan to me. I'll wait a few days to see if David or anybody has anything else about this, otherwise I'll apply this solution. I tried to use the conditional dependency [linux-any] for this package (K3D *can* work without this library, only that it has the related features disabled); but pbuilder doesn't support it and I was told that the daemons on buildd farm don't support it either, although there were people trying to fix it. Maybe there's a way to get this working now. I think that conditional build-dependencies should work. It's indeed true that edos-debcheck on the wanna-build side might not, but if this is the case please file a bug against buildd.debian.org after it has been uploaded. The package can be given to the builders overriding this check, too. Again, maybe the solution of aqsis might help here too. OK, same as above. Thanks for the help :) Cheers. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201008061948.09431.manuel.montez...@gmail.com
