Bug#756078: transition: gnat
Am 26.07.2014 01:13, schrieb Emilio Pozuelo Monfort: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition There's been an ongoing ada transition for a while. gnat in testing depends on gnat-4.6 and gnat in sid depends on gnat-4.9, and the gnat rdeps depend on both gnat and gnat-4.6 in testing and gnat and gnat-4.9 in sid, and gnat-4.6 and gnat-4.9 are not coinstallable. This means gnat can only migrate together with all its rdeps, as otherwise the rdeps would become uninstallable. I will make bugs for the rdeps that still need fixing block this bug. making debian-ada aware of the transition. Might be good to CC debian-ada in the future. -- 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/53d365cb.10...@debian.org
Bug#756078: transition: gnat
On 26/07/14 10:24, Matthias Klose wrote: Am 26.07.2014 01:13, schrieb Emilio Pozuelo Monfort: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition There's been an ongoing ada transition for a while. gnat in testing depends on gnat-4.6 and gnat in sid depends on gnat-4.9, and the gnat rdeps depend on both gnat and gnat-4.6 in testing and gnat and gnat-4.9 in sid, and gnat-4.6 and gnat-4.9 are not coinstallable. This means gnat can only migrate together with all its rdeps, as otherwise the rdeps would become uninstallable. I will make bugs for the rdeps that still need fixing block this bug. making debian-ada aware of the transition. Might be good to CC debian-ada in the future. Thanks, I wasn't aware of that list. I Cc'ed Ludovic and Nicolas (maintainers of the gnat package) instead. Will keep that in mind for the future. Emilio -- 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/53d374cc.1080...@debian.org
Re: libquazip transition
On 17/07/14 19:25, Emilio Pozuelo Monfort wrote: Hi, I see there's a transition for libquazip. I was going to schedule binNMUs for the rdeps, but the -dev package got renamed from libquazip0-dev to libquazip1-dev, but with the latter providing the former (I guess to allow binnmus). That won't work at least with freemedforms-project because that build depends on libquazip0-dev (= 0.4.4). I'm not even sure it would work for marble and tupi, because libquazip0-dev is still around, and that may be picked up by the buildds instead of libquazip1-dev. May I ask why the -dev package is versioned, instead of simply being libquazip-dev, as I think it should be? Can you fix freemedforms-project to build-depend on libquazip-dev or libquazip1-dev? So, can you rename the -dev package to libquazip-dev? Emilio -- 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/53d37ad2.4060...@debian.org
Bug#755212: transition: protobuf-c
On 18/07/14 22:19, Robert Edmonds wrote: * The header file (protobuf-c.h) which compiled .pb-c.h files must include. This is shipped in the libprotobuf-c0-dev package (protobuf-c 1.0.0), or the libprotobuf-c-dev package (protobuf-c = 1.0.0). (libprotobuf-c-dev Provides: libprotobuf-c0-dev, which smoothes the transition for packages with an unversioned build-dependency on libprotobuf-c0-dev.) I just realized that that's not going to work, because the old libprotobuf-c0-dev is still available, and so packages that build-depend on that will get libprotobuf-c0-dev. So they'll need sourceful uploads to build-depend on the new (unversioned) libprotobuf-c-dev. Emilio -- 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/53d3ae54.4040...@debian.org
Re: libquazip transition
On 26/07/14 11:54, Emilio Pozuelo Monfort wrote: On 17/07/14 19:25, Emilio Pozuelo Monfort wrote: Hi, I see there's a transition for libquazip. I was going to schedule binNMUs for the rdeps, but the -dev package got renamed from libquazip0-dev to libquazip1-dev, but with the latter providing the former (I guess to allow binnmus). That won't work at least with freemedforms-project because that build depends on libquazip0-dev (= 0.4.4). I'm not even sure it would work for marble and tupi, because libquazip0-dev is still around, and that may be picked up by the buildds instead of libquazip1-dev. Indeed, it doesn't work. sbuild picks up libquazip0-dev. So I suggest you do the following: 1: Rename libquazip1-dev to libquazip-dev. 2: Upload the rdeps with a build-dependency on the new libquazip-dev. Future transitions will be easier as the -dev package won't be renamed. Emilio -- 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/53d3aece.9040...@debian.org
Bug#755212: transition: protobuf-c
Emilio Pozuelo Monfort wrote:
On 18/07/14 22:19, Robert Edmonds wrote:
* The header file (protobuf-c.h) which compiled .pb-c.h files must
include. This is shipped in the libprotobuf-c0-dev package
(protobuf-c 1.0.0), or the libprotobuf-c-dev package (protobuf-c
= 1.0.0). (libprotobuf-c-dev Provides: libprotobuf-c0-dev, which
smoothes the transition for packages with an unversioned
build-dependency on libprotobuf-c0-dev.)
I just realized that that's not going to work, because the old
libprotobuf-c0-dev is still available, and so packages that build-depend on
that
will get libprotobuf-c0-dev. So they'll need sourceful uploads to build-depend
on the new (unversioned) libprotobuf-c-dev.
Hi, Emilio:
Are you sure about that? protobuf-c-compiler has:
Depends: ${shlibs:Depends}, ${misc:Depends}, libprotobuf-c-dev (=
${binary:Version})
Which will force libprotobuf-c-dev to be installed. And
libprotobuf-c-dev has:
Depends: libprotobuf-c1 (= ${binary:Version}), ${misc:Depends}
Provides: libprotobuf-c0-dev
Conflicts: libprotobuf-c0-dev
Replaces: libprotobuf-c0-dev
Breaks: protobuf-c-compiler ( 1.0.0~)
Which will force libprotobuf-c0-dev to be uninstalled.
I *think* what will happen is that if a package does:
Build-Depends: protobuf-c-compiler
or
Build-Depends: protobuf-c-compiler, libprotobuf-c0-dev
They will end up with protobuf-c-compiler (1.0.0-1) and
libprotobuf-c-dev (1.0.0-1) installed, which is what is desired.
I think all of the packages I listed in my original email had a
build-dep on either protobuf-c-compiler only, or protobuf-c-compiler and
libprotobuf-c0-dev. (I don't think there are any with just
libprotobuf-c0-dev.)
The only package with a versioned build-dep on libprotobuf-c0-dev is
osm2pgsql, which needs other sourceful changes anyway. I think with the
pending upload of osm2pgsql (#756112) there will be no more packages in
the Debian archive with a versioned build-dep on libprotobuf-c0-dev, and
it can be removed from the archive?
--
Robert Edmonds
edmo...@debian.org
--
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/20140726141855.ga...@mycre.ws
Processed: tagging 754275, tagging 754446, tagging 755018
Processing commands for cont...@bugs.debian.org: tags 754275 + wheezy Bug #754275 [release.debian.org] pu: package php5/5.4.4-14+deb7u13 Added tag(s) wheezy. tags 754446 + wheezy Bug #754446 [release.debian.org] wheezy-pu: fix #609457 in supervisor package Added tag(s) wheezy. tags 755018 + wheezy Bug #755018 [release.debian.org] pu: package hawtjni/1.0~+git0c502e20c4-3 Added tag(s) wheezy. thanks Stopping processing here. Please contact me if you need assistance. -- 754275: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754275 754446: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754446 755018: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755018 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.140638537126661.transcr...@bugs.debian.org
Bug#746388: transition: packagekit 0.9
2014-07-09 21:35 GMT+02:00 Matthias Klumpp m...@debian.org: 2014-07-09 20:13 GMT+02:00 Niels Thykier ni...@thykier.net: Hi, Any news on this? AFAICT, we are still waiting for an upload of PackageKit to experimental. Once in experimental, our tooling should auto-generate the desired tracker your transition. Yes, sorry for the lack of feedback... There were some adjustments needed upstream for this first (almost completely done now), and then I got cought by personal things which are eating up my time right now. But I expect 0.9.x to be available in experimental this month (likely around 24.), together with all its reverse dependencies. That stuff is in experimental now, and it lokks like two trackers have already been correctly auto-generated :-) Cheers, Matthias -- I welcome VSRE emails. See http://vsre.info/ -- 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/caknhny9ajhkns_03xm7rofquw4ukqj_ehuaduqfux+yuhy3...@mail.gmail.com
Re: P-a-s for stable and stable-security
On Sat, Jul 12, 2014 at 06:55:09PM +0100, Adam D. Barratt wrote:
tl;dr: do stable and stable-security chroots apply P-a-s correctly?
DSA 2952-1 updated kfreebsd-9 in wheezy-security. As it was built on all
architectures for which kfreebsd-9 was available in wheezy, it was then
also accepted in to proposed-updates. It appears that packages for some
other architectures - arm{el,hf}, ia64, mips, powerpc, s390{,x} and
sparc - were subsequently built by the buildds in wheezy chroots.
The kfreebsd-9 source package in wheezy has Architecture: any all.
That changed in unstable at some point last year, and the package was
subsequently removed from the sid branch of P-a-s in May.
However, the wheezy branch of P-a-s still contains:
%kfreebsd-9: kfreebsd-i386 kfreebsd-amd64 i386 amd64 mipsel hurd-i386
# freebsd kernel 8.x
This raises a couple of questions:
- are the wheezy w-b databases filtered using the wheezy branch of
P-a-s?
- are the wheezy and wheezy-security w-b databases filtered using the
_same_ branch of P-a-s?
Oh well, you just uncovered a bug that was not exposed widely because there's
a fallback P-a-s in the toplevel directory:
* All the triggers source triggers/common.
* common says at the top:
PAS_BASE=/srv/buildd.debian.org/web/quinn-diff
PAS_FILE=$PAS_BASE/$SUITE/Packages-arch-specific
* $SUITE is set subsequently but the file has already been source and hence
we get /srv/buildd.debian.org/web/quinn-diff//Packages-arch-specific for
all suites.
* This file exists and points to the sid checkout.
/srv/buildd.debian.org/web/quinn-diff/Packages-arch-specific -
sid/Packages-arch-specific
I'll fix that. Thanks.
Kind regards
Philipp Kern
signature.asc
Description: Digital signature
Re: libquazip transition
Le 26/07/2014 15:36, Emilio Pozuelo Monfort a écrit : On 26/07/14 11:54, Emilio Pozuelo Monfort wrote: So I suggest you do the following: 1: Rename libquazip1-dev to libquazip-dev. This has been corrected in the v0.6.2-2 of the libquazip package (thanks to Andreas). 2: Upload the rdeps with a build-dependency on the new libquazip-dev. I'm not sure to have the correct skill to do this. Can someone help me? Future transitions will be easier as the -dev package won't be renamed. Ok. FYI, the new version 0.7.0-1 is already available but yet uploaded. Emilio Thanks you for your help. -- Eric Maeker GPG: C217 B1B7 80E8 0381 FD5B C3A5 75D4 AE85 B952 0933 signature.asc Description: OpenPGP digital signature
Re: Debian/ppc64el feasiability to become an official architecture
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 probablly mostly right but i'm sure others will point out any errors. I would like to share the ppc64el port's status with you, and check if it is feasible to consider it as an official port for the next Debian release, or, what it may be missing for that. quite a bit needs to be done and I personally think it's unlikely any new architectures will make it in time for the jessie freeze at this point. The first step is going to be persuading the ftp masters to let you into the debian archive. You can see the ftpmasters critera at https://ftp-master.debian.org/archive-criteria.html . Right, as I understand we are on track to meet all those criteria. We have a good archive coverage, a debian installer, fast machines doing the build, and, finally a DD helping us. It sounds like the main thing you will need to do to meet them is push your fixes into debian proper so ppc64el can be built without external patches. Right?.What do you mean by built? We have a huge amount of packages building for ppc64el without external patches. At this time, we already built more than 8k8 source architecture-dependent packages (of almost 10K) for this platform[1] Also, the debootstrap packages are all BFS on ppc64el, and if you want a environment that contains git, openjdk, ssh, vim and latex, less than 10 bugs need to be accepted[2] [1] http://ftp.unicamp.br/pub/ppc64el/debian/buildd-upstream/build_logs/Uploaded.html [2] https://wiki.debian.org/ppc64el/topBugs So, I understand that we build a whole amount of things without any external patches. Merely submitting patches to the BTS for issues specific to your architecture is not sufficient. You will almost certainly have to perform non-maintainer uploads (NMUs) to deal with unresponsive maintainers. While in principle you can ask for sponsorship for NMUs if you want to actually get things moving in a reasonable timeframe you will need at least one Debian Developer (DD) on your team to upload them. Right. We have been involved and with a lot of NMU helps. Also, Adam (who is the DD) kindly agreed to help this architecture. He is rebuilding everything from source using his key, so, the packages become signed by a DD, and it might be imported by FTP master. You will also need at least one DD on the port team to satisfy the ftpmaster critera. Ideally you want more. 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 but not ppc64? is there hardware that will run both? what is the relative prevalance of each of these. If most hardware that can run ppc64el can also run ppc64 then are there significant technical advantages other than compatibility with badly written software of going little endian? Right, at the moment, all new hardware that can run ppc64el can also run ppc64. The current Power machines are bi-endian, so, you can run both architectures in the same hardware. At the same time, they are not compatible, since the ppc64el is based on a fresh new ABI, while the ppc64 and powerpc uses the old ABI. So, you will not be able to do a multi-arch between ppc64/powerpc and ppc64el. Also, ppc64el started with the POWER8 only processor, and the compiled packages might not be compatible with the old ppc64/powerpc hardware ISA. It's not strictly a requirement but it would likely help immensely to get the architecture on debian-ports.org so that maintainers can easilly see if their packages are failing and porters for other new ports (i've been helping out a bit with arm64 myself) can see if ppc64el is also failing. Right. Ppc64el is pursuing to get into debian-ports since the beginning of the year, but, there is lack of resources (CPU and memory IIRC) on debian-ports machines, so, that is the motivation that we didn't get into debian-ports. The same is happening with other architectures, AFAIK. I have been working with the debian-ports folks, and as soon as the lack of resources get sorted out, we might move our arch to debian-ports. Meanwhile, we have our own buildd and wanna-build[3] that is in sync with every new package that arrives at Debian, meaning that we are building every single package that show up in the unstable archive. [3] http://ftp.unicamp.br/pub/ppc64el/debian/buildd-upstream/build_logs/ If and when the ftpmasters decide to include your architecture a minimal set of packages will be imported and everything (including when possible the minimal set) must be rebuilt. This will take time and will likely involve more NMUs. It is likely you will need to NMU to fix issues that are not
Debian PPC test video problem with G5 Quad
Hi guys installed the test and installation progress everything goes fluid At first system boot no video at all on the Xorg Only Black Screen , the terminal video is corrupted and not perfect. On Wheezy 7.5 everything was working (except the audio) My Configuration PowerMac G5 Quad 8Gb , Nvidia 7800gtx 512mb Regards Luigi -- 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/blu436-smtp244ed887003339d453132bec8...@phx.gbl
Re: P-a-s for stable and stable-security
Hi, On Sat, Jul 26, 2014 at 09:29:47PM +0200, Philipp Kern wrote: Oh well, you just uncovered a bug that was not exposed widely because there's a fallback P-a-s in the toplevel directory: * All the triggers source triggers/common. * common says at the top: PAS_BASE=/srv/buildd.debian.org/web/quinn-diff PAS_FILE=$PAS_BASE/$SUITE/Packages-arch-specific * $SUITE is set subsequently but the file has already been source and hence we get /srv/buildd.debian.org/web/quinn-diff//Packages-arch-specific for all suites. * This file exists and points to the sid checkout. /srv/buildd.debian.org/web/quinn-diff/Packages-arch-specific - sid/Packages-arch-specific I'll fix that. Thanks. should be fixed. Hopefully. Kind regards and thanks Philipp Kern signature.asc Description: Digital signature
Re: Debian/ppc64el feasiability to become an official architecture
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 probablly mostly right but i'm sure others will point out any errors. I would like to share the ppc64el port's status with you, and check if it is feasible to consider it as an official port for the next Debian release, or, what it may be missing for that. quite a bit needs to be done and I personally think it's unlikely any new architectures will make it in time for the jessie freeze at this point. The first step is going to be persuading the ftp masters to let you into the debian archive. You can see the ftpmasters critera at https://ftp-master.debian.org/archive-criteria.html . Right, as I understand we are on track to meet all those criteria. We have a good archive coverage, a debian installer, fast machines doing the build, and, finally a DD helping us. It sounds like the main thing you will need to do to meet them is push your fixes into debian proper so ppc64el can be built without external patches. Right?.What do you mean by built? We have a huge amount of packages building for ppc64el without external patches. At this time, we already built more than 8k8 source architecture-dependent packages (of almost 10K) for this platform[1] Also, the debootstrap packages are all BFS on ppc64el, and if you want a environment that contains git, openjdk, ssh, vim and latex, less than 10 bugs need to be accepted[2] [1] http://ftp.unicamp.br/pub/ppc64el/debian/buildd-upstream/build_logs/Uploaded.html [2] https://wiki.debian.org/ppc64el/topBugs I intepret the must be built without external patches as it must be possible to have a self-contained subset of debian where all packages can be built on your architecture from pure debian source packages and where all build-dependencies are satisfiable. When you are added to testing you will be added as a broken and fucked (release team's terminology not mine) architecture. To get out of this state you will need to get and keep your port in a healthy state in testing. That will mean fixing (in some cases through NMUs) issues that are blocking migration of packages you need (whether or not those issues are related to your architecture) and fixing any architecture specific build failures as quickly as possible (since when you are in the broken and fucked state your builds will not be blockers for testing migration so a new upload that breaks your architecture will be able to migrate). Right. Do you recommend us to start building packages from 'testing' right now? We can create another buildd instances that only build testing and we can see how healthy it is. There isn't a lot of point IMO. Your ports health in debian testing will be more related to it's health in debian unstable than to it's health in a seperate rebuild of testing since the main way testing is updated is through migrations of source and binaries from unstable. The key thing is that binaries only migrate from unstable to testing either alongside source packages or when the source version in testing and unstable matches. What this means is that an architecture newly added to testing will be missing many packages. To get those packages into place generally means getting their version in testing and unstable into sync and that can mean fixing bugs that are not only not specific to your architecture but don't even directly affect it. It's technically possible to add binaries to testing for a package where testing and unstable are out of sync by binnmuing to TPU but AIUI the release team don't like this to be done on a routine basis. -- 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/53d4300d.7000...@p10link.net
Bug#755539: transition: hdf5
Emilio Pozuelo Monfort a écrit , Le 25/07/2014 09:22: On 24/07/14 20:10, Gilles Filippini wrote: I am currently rebuilding every affected package to prepare debdiff patches. I'll need a week or so to complete this task. Let us know when that's done. It took less time than I thought. Here is the new status of affected packages: No action required: magics++ octave-bim octave-msh python-shogun vtk Useless bin dependency on hdf5: getdp #755973 insighttoolkit4 #756015 oasis3 #755681 slepc #755180 binNMU required: armadillo dolfin mathgl ovito (blocked by #756108) paraview(blocked by #756108) shogun vtk6(blocked by #756108) Fix required (patch proposal ready): adios aster cdo cmor code-saturne exodusii flann gdal gmsh gpiv gpivtools grads h5utils hdf-eos5 jhdf libcgns libgpiv libmatio libpdl-io-hdf5-perl libvigraimpex med-fichier meep meep-lam4 meep-mpich2 meep-mpi-default meep-openmpi minc mpb ncl netcdf nexus octave petsc pygpiv pytables r-cran-hdf5 ruby-hdfeos5 salome-kernel scilab stimfit syrthes tessa xdmf xmds2 yorick-hdf5 Depends on deprecated hdf5 mpi-posix API: h5py silo-llnl Others: gnudatalanguage FTBFS blocked by plplot Thanks, _g. signature.asc Description: OpenPGP digital signature
