On 11 December 2010 16:40, Stephen Kitt <st...@sk2.org> wrote: > On Sat, 11 Dec 2010 17:28:10 +1030, Ron <r...@debian.org> wrote: >> On Fri, Dec 10, 2010 at 10:29:24PM +0100, Matthias Klose wrote: >> > On 23.11.2010 12:49, Dmitrijs Ledkovs wrote: >> > >debian-gcc is a bit specific to the native libc based toolchains and >> > >cross-toolchains using libc. I didn't manage to find an easy place to >> > >plugin mingw-w64 bootstrap into that packaging. >> > >> > You might want to have a look at Marcin's cross-build packages, >> > using the gcc-, binutils- and eglibc- source packages. >> >> I wasn't aware of Marcin's work, but I also agree this is probably >> the best avenue to explore if these are all building from identical >> source. I believe Robert's original attempt even did exactly this, >> and I tried to point Stephen in this direction too when he first >> contacted me, but I think that point got lost, and I got too busy >> to point again in more detail immediately. > > I'm not sure whether it got lost or not, my packages (with Dmitrijs' > contributions) currently build-depend on binutils-source and gcc-4.5-source > and avoid duplicating anything from the original binutils and gcc packages; in > fact I went to some effort (see my bug reports against gcc-4.5-source, now > resolved) to make sure the resulting packages would not only use the tarballs > provided in the -source packages but also apply any relevant patches. >
I was using the same strategy independly from Stephen with my original mingw-w64-toolchain package which is on launchpad. The only difference is that I was supporting both *-source packages and vcs checkouts for daily builds, which has now stalled due to bzr issues on launchpad. Overall the build strategy was about the same, sans some minor details. >> AIUI, the main problem with this is that the distro archive tools >> currently don't have good support for ensuring these 'binary' -source >> packages will remain available and linked to the derivative binary >> debs that might be built from them and uploaded to the distro. >> >> I believe ftp-master indicated to Robert that this could be fixed, >> but he went back to the quick and dirty duplication instead. If >> there are people with time to spend on this, talking to the archive >> maintenance people about what needs to be done for that, and when >> and how it might happen, is probably a productive step at this point. > > Indeed; I'm not sure what Matthias means by > > On Fri, Dec 10, 2010 22:29:24 +0100, Matthias Klose <d...@debian.org> wrote: >> this is already guaranteed by the gcj and gnat builds by only relying on >> the tarball in the gcc-4.x-source package. > > I imagine this could mean that the gcj and gnats builds don't use the patches > in the gcc-4.x-source package, and only use the tarball which won't change > from one Debian version to another (e.g. 4.5.1-1 to 4.5.1-2 etc.)... That > seems a shame to me since the patches are useful, and it still leaves the > problem of having a package build using gcc-4.5-source 4.5-1 for example, and > then gcc-4.5-source being replaced with version 4.5.1-1 with a new tarball. > > Matthias, is that what you meant? > As far as i can see from the build-logs source uploads of gcj / gnat use corresponding -source package and they do apply updated patches from the new -source package. The tarball is changed rarely, instead svn-updates patch is regenerated on subsequent uploads by Matthias. > I'll take it up with ftpmaster as you suggest, Ron! > > The other solution based on Marcin's work, which is also readily supported by > the existing -source packages, requires that the target architecture be > understood by dpkg (as pointed out by Dmitrijs); that may be a worthwhile > goal, notably since it solves the problem of how to provide build packages > for the various libraries people find useful, but it's a much longer-term > goal as far as I can see... > And it also solve the gcc package splitting problem (cpp, gcc, gcj, gnat etc) I have created a reprepro for mingw-i386 and mingw-amd64 on my alioth account and I'm building mingw-i386 packages using dpkg-buildpackage using -a option. I have updated dpkg_share files. I will try bootstrapping the arch again in pbuilder based on Debian experimental and then start uploading. It would be best to have access to a mingw-w64 alioth project. I have submitted the request for that, but still haven't received a reply. But that is another issue. I'll start mingw-common package on collab-maintainance with helper scripts, policy and updated dpkg-share. Repurposing Marcin's package for mingw is still work in progress. > Regards, > > Stephen > -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimhcszth58yx_=dsmafktff9jby9b_g�jc...@mail.gmail.com
