On 1 June 2018 at 21:45, Graham Inggs wrote:
> On 1 June 2018 at 21:43, Graham Inggs wrote:
>> r-cran-fastica also seems to be missing r-api-3.4 so doesn't appear on
>> the tracker, but needs a rebuild.
>
> Sorry, my mistake, please ignore.
OK, this time I'm pr
On 3 June 2018 at 00:29, Andreas Tille wrote:
> On Sat, Jun 02, 2018 at 11:22:07PM +0200, Emilio Pozuelo Monfort wrote:
>> > I found this while rebuilding r-cran-cummerbund (level 13) in Ubuntu,
>> > so anything else missing is a leaf package (or set of leaf packages, I
>> > guess).
>>
>> Do you n
Control: clone -1 -2
Control: reassign -2 src:llvm-toolchain-6.0 1:6.0.1-1
Control: retitle -2 resource directory changes with minor upstream release
Control: severity -2 important
Cloning and re-assigning so we can fix this for future releases.
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: binnmu
Hi release team
Deal.ii needs to be rebuild against openmpi to pick up headers in the
new multiarch locations (#849764). It will also need to be rebuilt
after petsc is rebuilt (#854905).
I suggest only sch
FWIW, builds of at least dune-common [1], elpa [2] and trilinos [3]
have become successful again since the upload of openmpi/2.0.2.
[1] https://buildd.debian.org/status/logs.php?pkg=dune-common&arch=mips64el
[2] https://buildd.debian.org/status/logs.php?pkg=elpa&arch=mips64el
[3] https://buildd.d
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
Hi release team
In order to fix #816699, ga was configured to build against
libarmci-mpi-dev from src:armci-mpi.
Around the same time, armci-mpi was binNMU'd for PIE rebuilds and it
was found that it FTBFS
Hi Thomas
I believe only the packages without autopkgtests; viz. cinder,
gnocchi, magnum, neutron and watcher needed unblocking, and I have
done those.
I have aged all of them though.
Regards
Graham
Hi Otto
On Thu, 20 Apr 2023 at 16:44, Otto Kekäläinen wrote:
> Can you please list the commits you do not accept so I can revert them and
> upload a 10.11.2-3 which you are then willing to approve?
I've had a look at some of the bugs closed in the changelog of
10.11.2-2; #866751, #1029165, #103
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: gelemen...@packages.debian.org
Control: affects -1 + src:gelemental
Please unblock package gelemental
[ Reason ]
This is a maintenance release from upstream with only the foll
Control: tags -1 + confirmed moreinfo
Hi Abou
Please go ahead and upload to unstable, and remove the moreinfo tag
once the package is built.
Regards
Graham
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: mobile-broadband-provider-i...@packages.debian.org
Control: affects -1 + src:mobile-broadband-provider-info
Please unblock package mobile-broadband-provider-info
[ Reason ]
Th
tags -1 + moreinfo
Hi Yadd
On Wed, 3 May 2023 at 04:51, Yadd wrote:
> here is the current debdiff (without the big removal of useless
> discoveryjs-json-ext/benchmarks)
I removed the moreinfo tag before realizing this is exactly the same
as the first debdiff.
You seem to have missed this comme
Control: tags -1 + moreinfo
Hi Bdale
On Mon, 22 May 2023 at 07:48, Bdale Garbee wrote:
> [ Risks ]
> The
> change for the -2 upload was a one-line change of the delivery path for a
> rarely-used systemd unit file in the packaging scripts (that is not enabled
> by default).
If this was an upload
Control: tags -1 + moreinfo
Hi Thomas
On Thu, 25 May 2023 at 16:12, Thomas Goirand wrote:
> unblock heat-cfntools/1.4.2-3
Debdiff looks good to me, but did you forget to upload?
Regards
Graham
Hi Christian
On Sun, 28 May 2023 at 18:48, Christian Kastner wrote:
> unblock hipsparse/5.3.3+dfsg-2
The debdiff looks good to me, however the migration of
hipsparse/5.3.3+dfsg-2 appears to be blocked by rocsparse/5.3.0+dfsg-3
[1].
Migrates after: rocsparse
Migration status for hipsparse (5.3.3
Hi Andreas
On Sun, 2 Jul 2023 at 19:57, Andreas Tille wrote:
> 45
>
> serious bugs that are all caused by the non-transition while we should
> have done one. That's pretty annoying for the people who need to do the
> work (in this case basically me).
IMHO, those autopkgtests regression bugs are
Hi Andreas
On Wed, 5 Jul 2023 at 15:51, Andreas Tille wrote:
> the just uploaded r-base 4.3.1-2 implements r-graphics-engine-* which is
> respected by dh-r 20230705 (also just uploaded). It would be great if
> you could setup transition tracker.
I don't think it's possible to set up a tracker f
Hi Dirk
On Wed, 12 Jul 2023 at 19:07, Dirk Eddelbuettel wrote:
> On 12 July 2023 at 19:47, Paul Gevers wrote:
> | On 12-07-2023 16:02, Dirk Eddelbuettel wrote:
> | > I can add the Breaks as a 'best of the worse alternative'. And, I
> presume, I
> | > can remove the existing four-year breaks? [1]
Hi Dirk
On Thu, 13 Jul 2023 at 16:25, Dirk Eddelbuettel wrote:
> Sounds good, and thanks for the assist! I should be able to provide a pretty
> quick turn-around.
I believe the attached patch should do the trick. It's basically
Paul's list from message #210, plus r-cran-interval and
r-cran-mald
Hi László
On Sat, 30 Jul 2022 at 14:28, László Böszörményi (GCS) wrote:
> Please note I do not maintain the reverse dependent fuse2 packages.
> But I will ping those maintainers as I don't want to ship Bookworm
> with fuse2. Its development stopped two years ago and fuse3 is here
> for six years
Hi Andreas
You should check on the package tracker pages for all the r-bioc-*
uploads and make sure they are ready to migrate along with
r-bioc-biocgenerics, e.g. r-bioc-cummerbund [1].
r-bioc-biocversion appears to break the autopkgtest of
r-cran-biocmanager/1.30.21.1+dfsg-1 in testing.
At leas
Hi Andreas
Sorry for the incomplete reply. I'll respond to the other points when
I have more time.
On Wed, 16 Aug 2023 at 11:24, Andreas Tille wrote:
> Do you see any further blockers?
tracker.d.o. is having some issues (see #1043546), but you can still
access up-to-date excuses here:
https://
Hi
On Sat, 19 Aug 2023 at 23:57, plugwash wrote:
> The package is blocked by autopkgtest failures on ppc64el and s390x. The
> reason
> for these failures is that the package (which is arch all) is not installable
> on these architectures because it depends on the ring crate which is not
> curren
Hi Andreas
On Wed, 16 Aug 2023 at 11:24, Andreas Tille wrote:
> Am Tue, Aug 01, 2023 at 01:06:41PM + schrieb Graham Inggs:
> > At least the following packages are failing their own autopkgtests in
> > unstable (list not complete):
> > r-bioc-cummerbund
> > r-bioc-d
Control: tags -1 confirmed
Hi Simon
I added your combined ben file to the tracker with some minor changes:
https://release.debian.org/transitions/html/gnome-shell-44.html
On Tue, 15 Aug 2023 at 17:18, Simon McVittie wrote:
> I think this is ready to go. Repeating the list of packages needing
>
Control: tags -1 + moreinfo
Hi Rock Storm
On Mon, 21 Aug 2023 at 09:03, Rock Storm wrote:
> Dear release team, I would like to request the removal of the printrun
> package (which I maintain) from *testing* due to bug #1050157 [1].
The severity of #1050157 is 'important', so it will just migrat
On Wed, 23 Aug 2023 at 12:04, Simon McVittie wrote:
> Please consider adding hints as follows:
>
> remove gnome-shell-extension-arc-menu/49+forkv29-3
> remove gnome-shell-extension-dashtodock/75-1
> remove gnome-shell-extension-easyscreencast/1.7.0-2
> remove gnome-shell-extension-flypie/21-1
> re
Control: tags -1 confirmed
Hi Balint
On Sun, 13 Aug 2023 at 11:33, Bálint Réczey wrote:
> I would like to update libnfs in unstable to the 5.0.2 version.
>
> It is built for all release architectures in experimental.
> The transition would involve libnfs and its reverse
> dependencies:
> far2l
Control: tags -1 confirmed
Hi Gianfranco
On Wed, 23 Aug 2023 at 17:09, Gianfranco Costamagna
wrote:
> Only openimageio and qtcreator have issues finding the new libyaml-cpp
> release, and this can be easily solved
> by dropping the Findyaml-cpp.cmake
>
> excluding unrelated failures and package
Hi Jeremy
On Thu, 24 Aug 2023 at 12:30, wrote:
> age-days 2 budgie-desktop/10.8-2
> age-days 2 gnome-remote-desktop/44.2-6
I added these earlier, along with a removal hint for:
gnome-shell-extension-impatience/0.4.8-2
> age-days 2 gnome-shell-extension-dashtodock/87-1
This was just uploaded,
Control: tags -1 confirmed
Hi Dmitry
On Mon, 14 Aug 2023 at 18:27, Dmitry Shachnev wrote:
> gnome-panel has a new release, which bumped SONAME of the shared library.
> I packaged it in experimental and verified that all reverse build-dependencies
> (gnome-applets, gnome-flashback, sensors-applet
Hi
libmutter-11-0 is gone from testing and gnome-shell has migrated. Is
anything outstanding, or can we consider this transition done?
Regards
Graham
Hi Kumar
On Wed, 2 Aug 2023 at 13:48, Kumar Appaiah wrote:
> I have uploaded the new Armadillo to experimental. I would like your
> permission to upload it to unstable. binNMUs should be sufficient for
> the reverse dependencies.
Have you checked that all the reverse-build-dependencies build wit
Hi David
On Tue, 25 Jul 2023 at 11:57, David Prévot wrote:
> Do you have a way to spot packages in Sid currently depending on
> symfony (<< 6~) in order to file bugs and eventually provide patches?
You could use a ben tracker for this.
I've set up something basic [1].
Feel free to submit MRs in
On Sun, 27 Aug 2023 at 18:21, Jeremy Bícha wrote:
> This transition is done, but I think gnome-shell-extension-dashtodock
> is popular enough that it's helpful to hint 87+really84-1 in sooner.
I marked gnome-shell-extension-dashtodock urgent and it has migrated, thanks.
Control: tags -1 confirmed
Hi Kumar
On Wed, 30 Aug 2023 at 07:22, Kumar Appaiah wrote:
> Thanks for the response. I have build the following packages
> successfully using the new Armadillo:
>
> gdal
> gnss-sdr
> phyx
> seer
> tvc
Great!
> I could not build mlpack since the build failed, but I
Hi
On Thu, 31 Aug 2023 at 12:03, Sebastian Ramacher wrote:
> Unfortunately trilinos is a key package and so cannot be removed without
> much effort from testing to complete the transition. Can you please take
> a look at fixing the current issues with trilinos?
As can be seen on salsa [1], packa
Control: reopen -1
Something went wrong and r-cran-rgdal/1.6-7+dfsg-1 migrated back into
testing on 2023-09-14.
Control: tags -1 confirmed
Hi Mo
On Fri, 27 Oct 2023 at 15:36, M. Zhou wrote:
> We can start the transition for utf8proc, which recently got an
> SOVERSION bump from 2 to 3. I tested the reverse dependencies
> on ppc64el and all of them are fine. The results for amd64 should
> be the same.
Plea
Control: tags -1 + moreinfo
Hi Andreas
On Fri, 27 Oct 2023 at 14:03, Andreas Tille wrote:
> The BioConductor transition will bump the virtual package
> r-api-bioc-3.17 to r-api-bioc-3.18.
>
> BTW, I'm aware that a couple of r-bioc-* packages did not yet migrated
> to testing due to some autopkgt
Hi Andreas
On Sun, 29 Oct 2023 at 04:33, Andreas Tille wrote:
> Can you confirm that packages uploaded to experimental can be moved in
> one rush from experimental to unstable without extra uploads?
I don't think this has ever been possible. The packages would need to
be uploaded again to unsta
Hi Matthias
On Tue, 31 Oct 2023 at 07:15, Matthias Klose wrote:
> Please setup a tracker to add python3.12 as a supported python3 version. This
> is
> non-blocking, as packages can migrate on their own once built. I'm not yet
> starting this, just want to have an overview of affected packages.
>
HI Andreas
On Sun, 29 Oct 2023 at 16:06, Andreas Tille wrote:
> Sorry, my question was probably confusing. I was not talking about the
> new packages. I was talking about the 170 r-bioc-* packages. If I
> upload these to experimental, will it be necessary to upload these to
> unstable again or
Control: tags -1 + moreinfo
Hi Andreas
On Mon, 13 Nov 2023 at 09:10, Andreas Tille wrote:
> Thanks to the hint from Charles I found that SparseArray is not new in
> Bioconductor and we can build the previous version with the current
> packages in unstable which I did and uploaded to new.
Thanks
Hi Nicolas and Rafael
It looks like the last blocker for this transition is plplot
5.15.0+dfsg2-10 failing its own autopkgtests [1].
Regards
Graham
[1] https://ci.debian.net/packages/p/plplot/
Control: tags -1 + confirmed
Hi Sébastien
On Thu, 9 May 2024 at 08:09, Sebastian Ramacher wrote:
> plplot is involved in the gnat and octave transitions. So let's do this
> one after gnat is done.
gnat 13 has migrated, please go ahead.
Regards
Graham
Hi Ansgar
On Fri, 10 May 2024 at 15:23, Ansgar 🙀 wrote:
> I'm happy to do that, but someone from the release team should ack the
> request. testing and related suites are their playground after all :-)
Please go ahead!
Regards
Graham
Hi Sébastien
On Sat, 11 May 2024 at 08:48, Sébastien Villemot wrote:
> Thanks. Uploaded and built on all release architectures.
binNMUs underway!
Regards
Graham
Hi Sébastien
octave-fits FTBFS on all architectures (#1070956),
and octave-stk FTBFS on 32-bit architectures (#1069477),
would you please take a look?
Regards
Graham
Control: tags -1 confirmed
Hi Matthias
On Fri, 21 Jun 2024 at 12:27, Matthias Klose wrote:
> it's now Mid June, let's go on with this transition. Please provide a
> transition slot now.
Please go ahead.
Regards
Graham
Hi Andreas
On Thu, 4 Jul 2024 at 05:56, Andreas Tille wrote:
> However, before doing so I would like to
> understand why packages like r-cran-factominer, r-cran-ggpubr,
> r-cran-vim, r-cran-systemfit, r-cran-survminer and others where I can't
> see any connection to r-cran-maptools were removed f
Hi Aurelien
On Mon, 15 Jul 2024 at 20:54, Aurelien Jarno wrote:
> Ok, I have upgraded them to serious. Note that at least for gopacket and
> rocm-hipamd, these bugs translate into autopkgtest regressions.
If I recall correctly, in Ubuntu the issue was first seen in the
autopkgtest failure of mum
Control: tags -1 confirmed
Quack
On Wed, 24 Jul 2024 at 16:12, Marc Dequènes wrote:
> I uploaded to experimental, passed NEW, and checked the level 2 rdeps
> are fine. Please let me know when uploading to unstable is convenient
> for you.
Please go ahead.
Control: tags -1 moreinfo
Hi Michael
On Wed, 24 Jul 2024 at 14:33, Michael R. Crusoe wrote:
> Hello. Bioconductor 3.19 has been out for a while, and 3.20 is on its way.
> Since 3.19 required new packages I decided not to wait for 3.20 in order to
> simplify that transition. I upgraded and uplo
Control: tags -1 confirmed
Hi Reinhard
On Tue, 23 Jul 2024 at 16:38, Reinhard Tartler wrote:
> I am aware that right now we have a number of transitions going on right now
> https://release.debian.org/transitions/, however, none of them are obviously
> interfering
> with the transition I'm prop
Control: tags -1 confirmed
Hi Matthias
On Wed, 17 Jul 2024 at 17:18, Matthias Klose wrote:
> updating from OpenJDK 17 to OpenJDK 21, as discussed in
> https://lists.debian.org/debian-java/2024/07/msg1.html
>From the list of bugs filed [1], only four packages are not already
fixed, pending,
Control: tags -1 confirmed
Hi Michael
On Fri, 16 Aug 2024 at 06:38, Michael R. Crusoe wrote:
> Thank you! As far as I can tell, everything is ready on our side.
In the meantime, gsl has finished, so please go ahead.
Regards
Graham
Hi Michael
On Wed, 28 Aug 2024 at 07:04, Michael R. Crusoe wrote:
> Please let me know if those "breaks" are harmless or if they should be
> reverted.
I think these are merely redundant because of the dependencies on
r-api-bioc-3.19.
You can remove them in a future upload, no need to upload on
Hi Michael
While I was preparing this email, it looks like the last 32-bit binary
removal was done [1]. \o/
I've been adding migration hints for the 32-bit autopkgtests, but it's
a manual process, so please let me know if any are still needed.
Please check the tracker pages for all the uploaded
Hi Michael
r-bioc-biocgenerics [1] has migrated and r-api-bioc-3.18 is gone from testing.
>From the release team's perspective, this transition is done.
There are still some packages that were not in testing for the
transition. Please check the transition tracker [2] for "good"
packages marked "
Hi Michael
After the first migrations, a second wave of about 70 migrations
happened after autopkgtests were retried. These can already be seen
on the tracker.
On Mon, 9 Sept 2024 at 09:44, Michael R. Crusoe wrote:
> We have a question about
> https://qa.debian.org/excuses.php?package=r-bioc-t
Hi Michael
On Mon, 9 Sept 2024 at 13:00, Michael R. Crusoe wrote:
> Can we get an exception/hint to ignore the s390x test failure for
> r-bioc-rhdf5 and the ppc64el test failure for r-bioc-tcgabiolinks?
I'd prefer that the failing tests were fixed (or skipped) in the
packages themselves.
Otherw
Hi All
I'm catching up after some AFK time, so I will just fill in some
details where I can.
On Tue, 28 Nov 2023 at 08:31, Paul Gevers wrote:
> > I have no idea why r-cran-seurat is not profiting from reduced waiting
> > time for the transition.
>
> Because its tests fail on armel. The reduction
Control: tags -1 + confirmed
Hi Andreas
On Tue, 28 Nov 2023 at 13:50, Andreas Tille wrote:
> Looks good. So if I understood correctly we are now rather waiting for
> some infrastructure issues to start the transition and we should simply
> sit-n-wait for the green light, right?
Please go ahead
Hi Andreas
On Sun, 3 Dec 2023 at 07:21, Andreas Tille wrote:
> Charles Plessy and I uploaded r-bioc-* packages until level 11.
> Unfortunately building of some packages seems to be blocked for
>
> A: some pandoc dependency reason
> pandoc depends on missing:
> - pandoc-data:amd64
Control: tags -1 + confirmed
On Thu, 30 Nov 2023 at 10:03, Matthias Klose wrote:
>
> wait until 3.12.1 is in the archive. 3.12.0+ isn't well handled as a
> version by some third party libraries.
binNMUs are now in progress with python3.12 3.12.0-7 in unstable.
python3.12 (3.12.0-7) unstable; ur
Hi Andreas
On Sun, 3 Dec 2023 at 07:21, Andreas Tille wrote:
> I have no idea how to work around this.
I found a workaround; demote pandoc from a Depends to a Recommends in
the r-cran-rmarkdown package. It seems that pandoc is not used for
building, at least for r-bioc-biovizbase, -degnorm, -io
Hi Andreas
On Wed, 13 Dec 2023 at 09:45, Andreas Tille wrote:
> as you might have noticed the upstream source for r-bioc-dss and
> r-bioc-demixt are missing and upstream did not answered two mails about
> this. Since the transition looks clean for me so far[1] after I fixed
> two autopkgtest iss
Hi Andreas
There are some packages that have still not migrated since the
previous r-api-bioc-3.17 transition in July 2023.
Links to their tracker pages, which should tell you what is needed, follow:
https://tracker.debian.org/pkg/r-bioc-cner
https://tracker.debian.org/pkg/r-bioc-dada2
https://t
Hi Abou
On Sat, 30 Dec 2023 at 10:17, Abou Al Montacir wrote:
> I've uploaded a broken version fpc_3.2.2+dfsg-24 unfortunately.
> This prevents building arch independent packages due to a silly mistake.
> This issue does not appear when you build both binaries and arch independent
> packages thu
Hi Matthias
On Sat, 20 Jan 2024 at 16:45, Matthias Klose wrote:
> Please setup a tracker for the python3-defaults transition, making 3.12
> the default Python version.
I've set up a tracker [1]. It is based on the tracker used for
python3.11 with the exclusion of source packages python3-default
Hi Nicolas, Matthias
On Sun, 3 Mar 2024 at 16:18, Nicolas Boulenguez wrote:
> Ben file:
>
> title = "gnat-13";
> is_affected = .depends ~
> "libgnat-8/libgnat-9/libgnat-10/libgnat-11/libgnat-12" | .depends ~
> "libgnat-13";
> is_good = .depends ~ "libgnat-13";
> is_bad = .depends ~ "libgnat-8/l
Control: tags -1 confirmed
Hi Matthias, Nicolas
On Sat, 2 Mar 2024 at 12:39, Matthias Klose wrote:
> when preparing GCC packages for time_t64, I noticed that we'll have an
> ABI change for libgnat as well. Instead of doing a gnat 12 -> 12+t64
> transition, let's do a gnat 12 -> 13+t64 transitio
Hi Dirk
On Thu, 18 Apr 2024 at 13:38, Dirk Eddelbuettel wrote:
> Right now it now only shows 'all reports (re-)running'.
That was because of the new upload, but I see the results there now.
The packages with failing autopkgtests are:
r-bioc-iranges/2.36.0-1
r-bioc-mutationalpatterns/3.12.0+dfs
Hi Nicholas
On Tue, 30 Apr 2024 at 12:33, Nicolas Boulenguez wrote:
> The time_t64 transition has triggered #1067453 in the Ada compiler,
> which is now fixed by gcc-13/13.2.0-24.
>
> The patch modifies the sources of the Ada standard library, so most
> Ada packages need a rebuild in order to upd
Hi Nicholas
I think the builds are on track, except for:
libtemplates-parser FTBFS on arch:all [1]
gprbuild FTBFS on arch:any [2]
libgnatcoll, libgnatcoll-bindings and libgnatcoll-db are blocked by
the builds of gprbuild
Regards
Graham
[1] https://buildd.debian.org/status/package.php?p=libtemp
On Sat, 4 May 2024 at 14:41, Andreas Beckmann wrote:
> src:armnn is stuck on i386,mips64el,ppc64el:
> https://buildd.debian.org/status/package.php?p=armnn
>
> There is an unsatisfiable
>Extra-Depends: libarm-compute-dev (>= 23.08+dfsg-3.1)
> while the package has restricted that B-D to the thr
Hi Nicholas
On Sat, 4 May 2024 at 12:21, Nicolas Boulenguez wrote:
> For some reason, some rebuilds succeeded without a +b1 version.
I think if the original uploads FTBFS then they would not have gained
a +b1 version.
> Their reverse dependencies is dep-waiting on the +b1 version.
> Please canc
Hi Andreas
So far, I haven't been able to get the package to build at all without
switching to source format 3.0.
I'll try now to see if I am able to skip the getmachine call.
For the record, debian/patches/010_build_scripts.diff already contains a
patch to allow it to build on kfreebsd:
+c
Some progress.
I pre-applied debian/patches/150-getmachine_multiarch.patch simply by
running:
$ patch -p 1 -i debian/patches/150-getmachine_multiarch.patch
...and then commented out the line:
#150-getmachine_multiarch.patch
..from debian/patches/series. I uploaded this to the Ubuntu PPA
b
]
+ * Team upload.
+ * Add debian/gbp.conf
+ * Add Homepage and Vcs fields
+
+ [ Graham Inggs ]
+ * Pre-apply debian/patches/150-getmachine_multiarch.patch.
+ * Update debian/rules: configure during the build-arch target.
+Closes: #763909
+
+ -- Graham Inggs Wed, 05 Nov 2014 11:59:03 +0200
Hi Release Team
Please unblock package viewmol
Applied existing patch to .diff.gz (before quilt) and configure during
the build-arch target to close #763909
Debdiff is attached
unblock viewmol/2.4.1-22
I checked the buildlogs of i386, arm64 and s390x and all show the
built .deb contains /usr/b
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
unblock wader/0.5.12-1.1
Hi release team
Please consider the attached debdiff to fix a FTBFS in wader (bug #768756).
Wader was removed from Jessie on 2014-12-08, however I only became
awar
Hi Jonathan
On 29 December 2014 at 20:12, Jonathan Wiltshire wrote:
> Control: tag -1 moreinfo
>
> On Mon, Dec 29, 2014 at 12:08:57PM +0200, Graham Inggs wrote:
>> Please consider the attached debdiff to fix a FTBFS in wader (bug #768756).
>> Wader was removed from Jessie o
On 29 December 2014 at 23:01, Graham Inggs wrote:
> Hi Jonathan
>
> On 29 December 2014 at 20:12, Jonathan Wiltshire wrote:
>> Control: tag -1 moreinfo
>>
>> On Mon, Dec 29, 2014 at 12:08:57PM +0200, Graham Inggs wrote:
>>> Please consider the attached
-reference/pkgs.html#archive-manip
On 29 December 2014 at 23:24, Alex Chiang wrote:
> Hi,
>
> I no longer have time to maintain wader and would be happy to turn over
> maintenance of the package.
>
> Sorry for any inconvenience I've caused.
>
> On Mon, Dec 29, 2014 at
Attached is an updated debdiff which includes upstream's fix for
#768756 and change of maintainer and uploaders fields.
It also includes some minor packaging changes which were committed to
wader's vcs [1], but not yet released (see #662823).
I haven't pushed any changes to wader's vcs as I am wai
Is any further information needed from me?
Wader has since been orphaned (#774577) and I will close that bug in
the changelog.
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://list
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
unblock motif/2.3.4-8
Hi release team
In order to fix RC bug #781995, I would like to upload a version of
Motif with upstream's fix for their bug #1565 reverted. I plan to
replace debian/
On 12 April 2015 at 22:19, Niels Thykier wrote:
> On 2015-04-12 21:47, Michael Gilbert wrote:
>> control: tag 781995 pending
>>
>> On Sat, Apr 11, 2015 at 7:41 AM, Graham Inggs wrote:
>>> Hi release team
>>>
>>> In order to fix RC bug #781995, I
On 12 April 2015 at 23:25, Michael Gilbert wrote:
> I can reschedule to delayed/0 if as the maintainer you say that's ok.
Understood. (Carefully not writing OK here, see below)
> If there isn't an RC bug about that, then it's likely not appropriate
> at this point in the freeze.
So far we only
On 13/04/2015 08:43, Julien Cristau wrote:
It's not appropriate in either, IMO. And even if it was, not at this
stage of the release.
Oh right. In Debian, xorg depends on:
xfonts-base (>= 1:1.0.0-1),
xfonts-100dpi (>= 1:1.0.0-1),
xfonts-75dpi (>= 1:1.0.0-1),
xfonts-scalable (>= 1:1.0.0-1
On 15 April 2015 at 21:12, Paul Gevers wrote:
> I saw that Graham already choose to just remove the symbol
> from the Ubuntu package. I believe that this is really a no-no,
> especially without careful investigation if other packages are using
> this symbol and this late in the release process.
Hi Michael
On 16 April 2015 at 02:29, Michael Gilbert wrote:
> Upstream intends that symbol to be private, so it should be unused in
> other packages. But for confidence that it doesn't lead to breakage,
> someone should build test the reverse dependencies, which is a large
> number. Graham can
retitle 782381 pre-approval: unblock: motif/2.3.4-6.2
thanks
On 16/04/2015 07:46, Michael Gilbert wrote:
On Thu, Apr 16, 2015 at 1:31 AM, Graham Inggs wrote:
If you uploaded 2.3.4-6.2 now, could it cause any harm? At least this
will get the package built and Release Team can still decide
On 25 April 2015 at 10:56, Julien Cristau wrote:
> Why does the symbols file include private symbols (i.e. why are
> supposedly private symbols being exported by the library in the first
> place)?
I don't know. I did ask upstream about it in their bug #1565 [1] and
got the following response:
I
+
+ [ Michael Gilbert ]
+ * Disable buggy fix for upstream bug #1565 (Closes: #781995).
+ * Remove symbol that was intended to be private (Closes: #782678).
+
+ -- Graham Inggs Mon, 25 May 2015 15:32:21 +0200
+
motif (2.3.4-6) unstable; urgency=medium
* Bump standards-version to 3.9.6 (no
introduced by upstream's updated fix applied in
+motif 2.3.4-5 (Closes: #782678).
+
+ -- Graham Inggs Fri, 19 Jun 2015 10:55:55 +0200
+
motif (2.3.4-6) unstable; urgency=medium
* Bump standards-version to 3.9.6 (no changes).
diff -Nru motif-2.3.4/debian/libxm4.symbols motif-2.3.4/debian/l
On 2 July 2013 21:03, Paul Gevers wrote:
>
> I think it is a good idea to get a strategy agreed. I think we should
> indeed pull in the maintainers of those packages as well as the RT.
>
> And couldn't (and shouldn't) we start testing this in experimental?
>
> OK, I will finish up with xmhtml and
Hi All
Using the ABI dumper [1] and compliance checker [2] utilities that were
annouced on the debian-devel list earlier today (thanks Paul), I
generated reports for xbae and xmhtml which I have attached.
Do the changes in xmhtml's ABI (a couple of globals changing from const
to non-const, a
201 - 300 of 320 matches
Mail list logo
