peter green wrote:
Retitle 684437 pre-approval for fpc/2.6.0-7 upload
Thanks
Since the last post on this bug report a load of updates related to
localisation have landed. Specifically the package was not previously
setup to support translations and as such was not translated. The
package has
Package: clang
Version: 3.0-6
Severity: grave
Tags: patch
x-debbugs-cc: debian-release@lists.debian.org
RT in cc because of proposed TPU upload.
Unfortunately it seems that the changes in 3.0-6 fixed clang on armel
but not on armhf.
root@debian:/# clang -v test.c
Debian clang version 3.0-6
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package fpc
I have just sponsored a fpc upload by Abou Al Montacir to unstable, fixing two
important bugs (note: one of the bugs was initially filed as normal but
speaking
Philipp Kern wrote:
Uhm, is it really required by policy to delete backup files that weren't
created by the package in the first place?
diff -Nru fpc-2.6.0/debian/fp-compiler.postrm.in
fpc-2.6.0/debian/fp-compiler.postrm.in
--- fpc-2.6.0/debian/fp-compiler.postrm.in 2012-05-06
Please unblock package scim-anthy version 1.2.7-5
It has been reported to us that the configuration setup
for scim-anthy crashes for some users (bug 682601 and
680988). This is due to the recent transition in the
package from gtk2 to gtk3.
We've also included build-flag hardening in this
Le dimanche 29 juillet 2012 23:31:39 Bart Martens, vous avez écrit :
Hi Rémi,
The patch fixes the bug. Why not simply use it ? Shall I upload an NMU ?
It does not address the real issue.
It must be pure luck that automake accepts it.
I don't know enough about automake internals to
1: the doc-base thing seems to have been copied straight from the sarge notes,
iirc this was caused by the old version of doc-base in woody so it shouldn't be
an issue for sarge-etch upgrades. Can anyone confirm/refute this.
2: the aptitude part also seems to have been copied straight from the
reassign 595829 libnspr4-dev
retitle 595829 dependencies in libxul-unstable.pc and libxul.pc are
stricter than dependencies of package
thanks
libxul.pc and libxul-unstable.pc contain Requires: nspr = 4.8.6 .
However xulrunner-dev only has an unversioned dependency on libnspr4-dev
and the
Package: metapixel
Version: 1.9.2-5
This looks like a typo, can you confirm/deny that you mean 1.0.2-5?
metapixel cannot be installed because it depends on libugif4g which is no more
available.
From a quick test it looks like a binnmu will fix this. CCing debian-release to
get one scheduled.
per http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=584156 flightgear
is uninstallable in sid due to dependencies on an outdated
libopenscenegraph. Trying to rebuild it reveals that simgear (one of
it's build-depends) has the same problem so please binnmu them both.
nmu simgear _1.9.1-2 .
the bug in question is 397788
it was closed by the upload of version 1:2.0.0+beta5-1 which then
migrated to testing.
it was later reopened because it wasn't in fact fixed,
britney now seems to think it affects unstable and not testing, i tried
marking the bug as found in 1:2.0.0+beta5-1 but
retitle 414944 libapt-pkg-perl and hence apt-file are uninstallable on
systems that preffer unstable
severity 414944 grave
CCing debian-release because a binnmu should be enough to fix this.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL
calling stuff i386 when it will not run natively on a 386 seems like asking
for confustion to me
why and when was this instruction emulation needed in the first place (that
is why and when was the userland changed to need it)
-Original Message-
From: Adeodato Simó [mailto:[EMAIL
: 04 October 2004 14:33
To: Peter Green
Cc: Adeodato Simó; debian-kernel@lists.debian.org;
debian-release@lists.debian.org; debian-boot@lists.debian.org
Subject: Re: Dropping 386 support
peter green wrote:
calling stuff i386 when it will not run natively on a 386 seems
like asking
Looks like if I build for unstable, I'll pick up a Depends on
libneon27-gnutls (= 0.29.5) which isn't in testing. Should I target
TPU instead?
Unfortunately t-p-u isn't an option in this case, as the package has the
same version in testing and unstable (dak requires that t-p-u uploads
satisfy
package: ifeffit
severity: serious
x-debbugs-cc: debian-release@lists.debian.org
ifeffit needs rebuilding against the new perl and it seems the buildds
can't build it due to the build-depends on the non-free package pgplot5.
--
To UNSUBSCRIBE, email to
openssl098 is still kept in testing by:
- ace (ICE on armel)
Taking a look at this one
- beid (RC-buggy, candidate for removal)
- ipsec-tools (#619687 #643570, has reverse dependencies)
- isakmpd (#622051, candidate for removal)
This bug has had a patch for several months, but the maintainer
- ace: There have been a number of gcc-4.6 updates, I gave
it back to see if the ICE has been fixed or not.
The build that resulted from the most recent give-back
failed but it did so in a VERY strange manner.
It claimed to install libzzlib-dev and zlib1g-dev yet it
failed to link against
armhf has now pretty much cleared the needs-build queue (the only things
left are non-free stuff and recently added stuff) and has built arround
89% of the archive (placing it between kfreebsd and ia64) with about
99.5% up to date (placing it between amd64 and i386). Would now be a
good time
Luke Kenneth Casson Leighton wrote:
On Tue, Jan 3, 2012 at 10:54 PM, Adam D. Barratt
a...@adam-barratt.org.uk wrote:
(fwiw, the not-yet-built list includes webkit and ruby1.9.1, each of
which have a number of other packages directly or indirectly stuck
behind them).
ahh... webkit.
Please requeue the binnmus of osptoolkit on all architectures except
armhf and s390x (which don't need a binnmu because they first built
the package after the openssl transition).
The previous binnmu attempt failed due to a linker issue, however
based on a combination of local testing and the
An initial push of packages to testing occurred with tonight's britney
run. There's a certain amount of uninstallability and loads of missing
packages still, but it's a start :)
I guess the next step is to try and get it to the point where it is
bootstrapable.
When I tried to bootstrap it
It looks like the previous binnmu picked up an old version of
liblwt-ocaml-dev leading to an uninstallable package.
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
Having discussed this and watched relevant commits in #debian-kbsd, I'm
fairly sure that kfreebsd-kernel-headers = 0.67 will fix failures due to
sys/soundcard.h (which caused the OSS plugin not to be built, causing
FTBFS), hence this dep-wait request. I know that a new enough version is in
the
A number of packages are uninstallable in armhf testing due to missing
libsoup2.4-1 (source package libsoup2.4)
The new version of this package is not migrating due to a build failure
on sparc which doesn't look like it will be fixed any time soon*.
I have tested locally and the version of
Could you schedule binnmus of pulseaudio, gconf and libatomic-ops (the
latter two along the the migration of psmisc from unstable will be
needed before gconf can actually be built but wanna-build should handle
that) and in armhf testing.
None of these packages look like they will migrate from
python-qt4 declares a breaks on python-kde4 (= 4:4.6.80-3+b1) due to
old builds being incompatible with new versions of python-qt4.
This is fine on most architectures but armhf and s390x still have
non-binnmu versions of python-kde4. Can you binnmu the package with a
+b2 version suffix on
Here are some more binnmus to get binary packages into armhf testing
that don't look like they will migrate from unstable any time soon.
nmu transfig hdf5 emacs23 libgtk2-perl audacious audacious-plugins
transfig vlc . armhf . testing . -m 'build for armhf testing'
nmu 3 netcdf . armhf .
Julien Cristau wrote:
hdf5 and friends will migrate soonish.
That wasn't the impression I got when looking at the list of blockers
for the transition bug, looking at the transition status page and asking
on irc.
vlc's already in sync.
It wasn't when I started putting the list together
We are currently awaiting a transition slot via debian-release.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=656839
Understood
According to the endorsed workflow, we should not upload to unstable without
approval from the release team:
peter green wrote:
Would you object to a NMU based on the version currently in unstable
that just fixes the FTBFS?
I have now prepared a NMU based on the version currently in sid that
only fixes the FTBFS. The debdiff is attatched.
libosip2 maintainers are you ok with this NMU?
diff -u
Thanks Peter.
That upload is OK.
Thanks
Since i'm not yet a DD could one of you guys please sponsor it?
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
Recent versions of the openjdk-6 package have stopped producing the
binary package openjdk-6-jre-zero on powerpc. The old binary is
currently preventing openjdk-6 migrating to testing. Should this old
binary be removed from the archive so the package can migrate?
--
To UNSUBSCRIBE, email to
http://wiki.debian.org/ftpmaster_Removals
That page says the request should ideally come from the maintainers with
the release team also being acceptable hence me sending a mail to them
rather than filing a removal request myself.
--
To UNSUBSCRIBE, email to
Afaict one of the key steps in getting an architecture to release status
is to deal with (prefferablly by fixing but I guess removing could also
be an option in some cases) any out of date packages for that
architecture in testing. Am I correct?
If so is there any easy way to get a list of
Adam D. Barratt wrote:
[dropped the non-existent debian-ftp@lists.d.o from CC]
On Fri, 2012-03-23 at 21:56 +, peter green wrote:
Afaict one of the key steps in getting an architecture to release status
is to deal with (prefferablly by fixing but I guess removing could also
be an option
Comments on / additions and corrections to the content of
http://release.debian.org/wheezy/arch_qualify.html would be appreciated,
as would any other information you think is relevant to helping us
determine armel's status for the release.
The statement that all but one armel buildd is at
I just found this:
http://boundarydevices.com/products-2/sabre-lite-imx6-sbc/
Highlights of the platform include:
o Quad-Core ARM Cortex A9 processor at 1GHz
Nice :)
o 1GByte of 64-bit wide DDR3 @ 532MHz
This is better than the average arm board but it's the same as
debian's current
Where does anything tell the system to use qemu to run stiff?
I could understand if binmisc was setup for it, but I see nothing that
should make it get used
AIUI the magic is supplied by binfmt-support and the debian qemu packages
--
To UNSUBSCRIBE, email to
| At least for s390 the problem is not buildd resources. s390 has a 31bit
| address space, which g++ manages to exhaust compiling this insane source
| file. That can't be fixed by rescheduling.
So what do we do?
My suggestion would be to drop the optimisation level to -O1 (and if that
gcc-defaults in testing depends on gccgo-4.6 which is no longer built by
the gcc-4.6 source package in unstable. The new gcc-defaults in unstable
is blocked from migrating due to the standoff between the release team
and the gcc maintainers over gcc-4.7. As a result of this gcc-4.6 cannot
I just uploaded a new fpc package to the repositry, there are no code
changes but there are a couple of fixes to packaging issues that I'd
like to see in the release.
1: When I added myself to uploaders I only added myself in control not
in control.in with the result that my changes were
When I look at I see there is nothing currently in the building state
and 9 packages in the needs build state 7 of which have been in that
state more than a week.
Is there a problem with the buildd?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact
Afaict the previous build attempt failed due to desynced apache
packages, that should now be ok.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
please unblock vtk 5.0.4-1.1 the only change is to disable optimisation
on arm to stop uic-qt3 segfaulting and breaking the arm build of fslview.
Previously the package was stuck behind some qt4 package (and someone
offered to do a TPU upload but afaict never actually did so) but that no
Adeodato Simó wrote:
please also requeue fslview on arm in TPU with a dep-wait on libvtk5-qt3
5.0.4-1.1
Done.
Unfortunately while the dep-wait WAS set (I saw it on jereons buildd
information pages) for some reason (maybe whatever information source
the dep-wait system uses is more
You're probably looking at an old log:
http://buildd.debian.org/build.php?pkg=fslviewarch=armver=3.0+4.0.2-3lenny2
As you can see (at least, right now), there is no log yet with a date
later than when I set the dep-wait.
Hmm I saw the dep-wait set sometime in the early hours of this
according to http://buildd.debian.org/pkg.cgi?pkg=universalindentgui
universalindentgui has a dep-wait set on libqt4-qt3support (
4.4.3-1) but the current version in the archive for all architectures
is only 4.4.3-1
It looks to me like someone accidently used rather than = when
setting a
reassign 520328 libvtk5-dev
retitle 520328 libvtk5-dev should have a versioned dependency on libvtk5
If libvtk5-dev is 5.2.1 but libvtk is only 5.0.4 (as seemed to happen
with all the buildd builds of caret 5.6.1~dfsg.1-3
http://packages.debian.org/source/unstable/caret) then a broken
symlink
Emboss has now moved openjdk-6-jdk to build-depends-indep so the arch
specific binaries should now be buildable on hppa. Please clear the
dep-wait (left over from a previous version) so the hppa buildd will
build it.
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a
Ari Pollak wrote:
Once again, that doesn't make any sense. Pidgin's configure only looks
for nss
You are indeed correct, I was misinformed by the pidgin developers on
irc, I have now worked out what really happened.
nss was forciblly updated in testing because it was blocking so many
looks like theese two pacakges need to go in together and britney can't
work that out on it's own.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
investigating 486260 I have discovered the following
the i386 package from the archive (uploaded by the nmuer) segfaults
the amd64 package from the archive (built by a buildd) runs and shows
the GUI (whether it does what it is supposed to I can't say as I don't
use the package)
A self built
peter green wrote:
investigating 486260 I have discovered the following
the i386 package from the archive (uploaded by the nmuer) segfaults
the amd64 package from the archive (built by a buildd) runs and shows
the GUI (whether it does what it is supposed to I can't say as I don't
use
I am wondering if it is a good idea to remove lilo entirely. At the
moment, lilo has been pulled from testing, and the code is in a shape
Can either version of grub handle all the cases that lilo can? for
example can either of them handle the situation where root is on lvm and
there is
Since openjdk is now available in main, wouldn't that be the best solution?
It would if it was in lenny but unfortunately openjdk was delayed hugely
by license issues :(. Now we have a situation where afiact openjdk will
only make it into lenny if one of the following happens.
*The rc
jcc has moved to using openjdk but old dep waits on the sun jdk are
still present on a number of architectures. Please remove them.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
my test results for pdftk (which has the same version in both lenny and sid)
build in sid: builds sucessfully
build in lenny: FTBFS
build in lenny with sids gcj-4.2, gcj-4.2-base, gij-4.2, libgcj8-1,
libgcj8-1-awt, libgcj8-dev, libgcj8-jar (that is all packages from the
gcj-4.2 source package
clp failed to build on m68k, arm and hppa. When I tried to build it on
my qemu arm sid system it built fine so I presume that whatever caused
theese build failures was a transiant issue.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL
Adeodato Simó wrote:
* Adeodato Simó [Sat, 09 Aug 2008 14:47:55 +0100]:
* peter green [Sat, 09 Aug 2008 14:00:55 +0100]:
clp failed to build on m68k, arm and hppa. When I tried to build it on
my qemu arm sid system it built fine so I presume that whatever caused
theese build
The maintainer for
icedtea-gcjwebplugin argued for this being contrib with wrong reasoning.
Where did he do that? I don't see any posts from the maintainer in the
bug report log (even the setting of pending wasn't done by someone on the
current maintainers list though they may be someone in the
I can't believe you're actually arguing that the solution against blindly
trusting a website is blindly trusting a binary blob.
I would rather use a secure free plugin than a secure non-free plugin,
but apparently that doesn't exist. Since the choice is between a secure
non-free plugin and an
A NMU of gem was made by Alexander Reichle-Schmehl [EMAIL PROTECTED]
mailto:tolimar%40debian.org to fix the rc bugs 421560, 484190 and
485798 and was unblocked by he. Unfortunately it has picked up a
depedency on a new upstream version of libquicktime which is blocking
it's transition to
Simon Josefsson wrote:
tor 2013-03-07 klockan 13:51 + skrev peter green:
I am a cofounder of a project called raspbian to provide a hard float
derivative of debian for the raspberry pi. A user reported a bug to us
about libpam-ubico related (so the reported claims) to char signedness
Ok, I can see how it can be confusing. who-uploads does show that it
was my gpg signature on the upload. It's just this way I sponsor any
other uploads were the code/changes I am not the author of.
IMO there is a big difference between asking someone to sponsor and
posting a patch to the BTS.
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please approve my upload for package clang, this fixes two issues one of which
is filed as a grave bug. The other I also judge to be grave but is not currently
filed as a bug in debian (if
peter green wrote:
Debdiff is attatched
Sorry forgot to attatch it, here it is.
diff -Nru clang-3.0/debian/changelog clang-3.0/debian/changelog
--- clang-3.0/debian/changelog 2013-02-10 14:47:29.0 +
+++ clang-3.0/debian/changelog 2013-03-28 18:03:16.0 +
@@ -1,3 +1,16
Jonathan Wiltshire wrote:
I'd rather not have the DEP-3 boilerplate in your first patch; with that
removed, please go ahead with an upload to unstable and ping this bug when
it is ready.
Done.
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of
It seems that Adam D. Barratt unblocked libarchive to fix the security
bug. Unfortunately that wasn't enough to get the package into testing.
Specifically it seems that s390x has not successfully built this package
for some time (since before s390x stopped being considered a broken and
fucked
Package: libarchive
Version: 3.0.1b-1
Severity: serious
Note: this bug report is a continuation of discussions in the unblock
bug for libarchive (
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704080 ).
my personal guess is that there's probably nothing s390x-specific to it,
it's probably
I am requesting a transition from libarchive12 to libarchive13. libarchive13
is from the latest release of libarchive (3.1.2). A soname bump was done
upstream due to some ABI changes, specifically with HFS support.
I notice the most recent experimental upload FTBFS on many architectures
with
Forwarding reply to my query to the bug report.
Original Message
Subject:re: Bug#706866: transition: libarchive
Date: Mon, 6 May 2013 20:17:37 -0400
From: Andres Mejia amejia...@gmail.com
To: peter green plugw...@p10link.net
References: 518842df.1000
I noticed libgeotiff-dfsg was not migrating to testing and discovered
that the reason was that liblas needed updating to also use
libtiff5-alt-dev. I prepared such an update and when I got no maintainer
response I NMUd it. That NMU has now reached migration age but it
doesn't seem to be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
I have an interest in debian on arm devices. My main interest in such
devices
is for their ability to act as (relatively) low power gateways between
embedded hardware and networks such as the internet.
I helped with bringing armhf up to release
I just ran into a particularlly nasty instance of bug 329192
As described in that bug nullmailer ignores permanent errors, has an
agressive retry policy and never times out messages stuck in the queue.
If a message that is too large for the smarthost to accept gets into the
queue this can
Johannes Schauer wrote:
Hi,
the following is a report of a successful implementation of what I have been
talking about with Niels Thykier during debconf13. The question was how
important it is for a source package to be compilable or exist in the first
place given an incomplete port which is in
Julien Cristau wrote:
That'll hopefully fix itself (or at least get better) once qt 5.2 hits
sid, as that's built on many more archs.
QT 5.2 has now hit sid but transmission is still in bd-uninstallable on
four release architectures where it has built in the past.
kfreebsd-*: blocked by
Please check qgis, that did FTBFS on arm* with
deduced conflicting types for parameter 'const T' ('double' and 'qreal {aka
float}')
qgis seems to be using qt4. The qreal==double on all platforms switch
was only for qt5 (it's way too late to make such a change in qt4 now).
--
To
While looking at build failures in raspbian I noticed that numpy could
not be imported in python 3.4 (
http://buildd.raspbian.org/status/fetch.php?pkg=pandasarch=armhfver=0.13.1-2stamp=1392881756
) . I confirmed that this was not a raspbian specific issue by testing
on debian armel.
I
While looking at the buildd pages for liblas I noticed the following
BD-Uninstallable explanation for kfreebsd-*
liblas build-depends on:
- libgdal-dev (= 1.10.0~)
libgdal-dev depends on:
- libcurl4-gnutls-dev
libcurl4-gnutls-dev depends on:
- libgnutls-dev
libgnutls-dev depends on:
-
Note: this is the perspective of a dd who is not directly involved with
powerc though I have come across some of your bug reports, nor am I a
member of the ftp or release teams. It's probablly mostly right but i'm
sure others will point out any errors.
I would like to share the ppc64el
Lennart Sorensen wrote:
On Fri, Jul 25, 2014 at 12:14:08AM +0100, peter green wrote:
Another question the ftpmasters will likely have is what is the
relationship between ppc64 and ppc64el. Is there hardware that will
run ppc64 but not ppc64el? is there hardware that will run ppc64el
Breno Leitao wrote:
Hi Peter,
Thank you for your reply.
On 07/24/2014 08:14 PM, peter green wrote:
Note: this is the perspective of a dd who is not directly involved with powerc
though I have come across some of your bug reports, nor am I a member of the ftp
or release teams. It's
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
nmu lhapdf_5.9.1-3 . arm64 . -m Rebuild against octave 3.8
The lhapdf package on arm64 was actually built against octave 3.8, unfortunately
it's not installable because octave declares
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package tightvnc
This upload of tightvnc adds arm64 support to the packages build system. The
code is all behind conditionals so it shouldn't affect other architectures.
Jonathan Wiltshire wrote:
Control: tag -1 moreinfo
On Sun, Nov 02, 2014 at 01:55:30PM +, peter green wrote:
This upload of tightvnc adds arm64 support to the packages build system. The
code is all behind conditionals so it shouldn't affect other architectures.
This is needed to make
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
When looking through the list of packages that are uninstallable in arm64
testing I belive the following TPU binnmus are appropriate towards the goal
of pushing the list of uninstallable
Tags 767759 -moreinfo
Thanks
peter green wrote:
The package is now uploaded and built on all release architectures
except mips. On mips it's currently sitting in needs-build.
The package is now built successfully on all release architectures
--
To UNSUBSCRIBE, email to debian-release-requ
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
I'm seeking approval for fixing the arm64 build failure in xfce4-notes-plugin.
The package FTBFS due to outdated config.sub/guess.
The maintainer doesn't have a problem with the changes
Control: tag -1 -moreinfo
I think you meant the non-attatched debdiff. ;p
Doh, here it is.
diff -Nru xfce4-notes-plugin-1.7.7/debian/changelog
xfce4-notes-plugin-1.7.7/debian/changelog
--- xfce4-notes-plugin-1.7.7/debian/changelog 2014-10-15 19:19:50.0
+
+++
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package umockdev
Version 0.8.8-1 of umockdev failed to build on arm64 with a testsuite failure
and as a result we currently have an out of data umockdev in arm64 testing.
Jonathan Wiltshire wrote:
Looks ok to me.
Ok, the maintainer has now made an upload which is substantially the
same* as my proposal. The upload has built successfully on all release
architectures.
unblock xfce4-notes-plugin/1.7.7-5
* he reworeded the changelog entry, used a non-nmu
Reopen 782976
Thanks.
On 24/04/15 22:49, Jonathan Wiltshire wrote:
On Mon, Apr 20, 2015 at 02:17:25AM +0100, peter green wrote:
Release team: can you clarify whether you intend to actually remove kfreebsd
from the jessie suite of the official archive before/during the jessie
release
Release team: theres a question for you at the end of the mail.
On 20/04/15 00:49, Cyril Brulebois wrote:
peter greenplugw...@p10link.net (2015-04-20):
Package: debian-installer-netboot-images
Severity: serious
The RC policy states Packages must be buildable within the same release..
In
This may need a binNMU:
haskell-trifecta (1.4.3-1 to 1.5.1.3-4)
Maintainer: Debian Haskell Group
9 days old (needed 5 days)
libghc-trifecta-dev/ppc64el unsatisfiable Depends:
libghc-charset-dev-0.3.7.1-1690c
libghc-trifecta-dev/ppc64el unsatisfiable Depends:
On 17/10/15 10:48, Maximiliano Curia wrote:
Hi,
On 17/10/15 03:55, peter green wrote:
There appears to be a transition going on with the libkdegames source
package which seems to require sourceful changes in the rdeps. A
substantial number of rdeps have transitioned but a substantial
There appears to be a transition going on with the libkdegames source
package which seems to require sourceful changes in the rdeps. A
substantial number of rdeps have transitioned but a substantial number
have not and no bug reports seem to have been filed on said rdeps, nor
does there seem
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
Libstdc++6 declares a breaks on python3-taglib (<= 0.3.6+dfsg-2+b2),
presumablly as part of the big c++ ABI transition. However the binnmu
versions are out of sync across architectures
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
nmu starpu_1.1.4+dfsg-1 . ALL . -m Rebuild for gcc 4.9.3
starpu seems to have a strict dependency against the version of gcc-4.9 it was
built against. This is blocking the migration of
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
There were problems with using psi4 built with gcc-4.9 with a gcc-5
libstdc++6. As a result a breaks was added to libstdc++6 and psi4 was
binnmu'd.
However the binnmus on arm64 and
1 - 100 of 155 matches
Mail list logo
