Re: Bug#594179: dpkg armhf patch acceptance status?
After a short discussion with Steve and later with Guillem on IRC, I think it's time to make a final decision about this issue. To cut the long story short, I agree with Steve's proposal on this: arm-linux-gnueabi_hf If we all agree on this, let's please have a dpkg release with the final armhf triplet included so that I can continue work on the other issues (d-i support, multiarch migration) :) Regards Konstantinos -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTi=fpako8snjkz+j-evoqs3f6mmrbgduyaabf...@mail.gmail.com
Re: dpkg armhf patch acceptance status?
Konstantinos Margaritis wrote: To cut the long story short, I agree with Steve's proposal on this: arm-linux-gnueabi_hf What is the purpose of the underscore? In other words, what is the advantage over arm-linux-gnueabihf? I worry that some tools may not like it --- for example, package names like mlton-target-arm-linux-gnueabi_hf are not allowed. Which looks very much surmountable, but just in case, it seems prudent to ask. Just to be clear, this is not an objection (both triplets look fine to me). I ask in the hope of getting the rationale well documented. Thanks, Jonathan -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110314084711.GA23600@elie
Re: dpkg armhf patch acceptance status?
On 14 March 2011 10:47, Jonathan Nieder jrnie...@gmail.com wrote: Konstantinos Margaritis wrote: To cut the long story short, I agree with Steve's proposal on this: arm-linux-gnueabi_hf What is the purpose of the underscore? In other words, what is the advantage over arm-linux-gnueabihf? I worry that some tools may not like it --- for example, package names like mlton-target-arm-linux-gnueabi_hf are not allowed. Which looks very much surmountable, but just in case, it seems prudent to ask. Just to be clear, this is not an objection (both triplets look fine to me). I ask in the hope of getting the rationale well documented. Sigh, fine, whatever. Nothing personal Jonathan, it just feels extremely frustrating to always have a point raised when we're about to finally make a decision - and yes, it's a very valid point that you raised. So, yes, ok, finally, let's agree -for the last time I hope- on the underscore-less triplet: arm-linux-gnueabihf So, can we please, please, close this bug and get on with other issues? Regards Konstantinos -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktiksycywojg0_ne3kkc9cxn9yus-xefm4rq51...@mail.gmail.com
Re: dpkg armhf patch acceptance status?
On Mon, Mar 14, 2011, Jonathan Nieder wrote: What is the purpose of the underscore? In other words, what is the advantage over arm-linux-gnueabihf? I worry that some tools may not like it --- for example, package names like mlton-target-arm-linux-gnueabi_hf are not allowed. Which looks very much surmountable, but just in case, it seems prudent to ask. Just to be clear, this is not an objection (both triplets look fine to me). I ask in the hope of getting the rationale well documented. I think the underscore was originally proposed for multiarch triplets; Guillem sent a patch without underscore upstream. I've heard an independent suggestion to use an underscore from GCC upstream, so it seems underscore might well end up in this triplet. Note that the amd64 triplet already uses an underscore (in the CPU part though): x86_64-linux-gnu, so I don't think the presence of underscore should be a new technical issue introduced by armhf. It's probably up to the GCC upstream folks to decide on this. Cheers -- Loïc Minier -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110314110042.gb18...@bee.dooz.org
Re: dpkg armhf patch acceptance status?
On Mon, Mar 14, 2011 at 12:00:42PM +0100, Loïc Minier wrote: On Mon, Mar 14, 2011, Jonathan Nieder wrote: What is the purpose of the underscore? In other words, what is the advantage over arm-linux-gnueabihf? I worry that some tools may not like it --- for example, package names like mlton-target-arm-linux-gnueabi_hf are not allowed. Which looks very much surmountable, but just in case, it seems prudent to ask. Just to be clear, this is not an objection (both triplets look fine to me). I ask in the hope of getting the rationale well documented. I think the underscore was originally proposed for multiarch triplets; Guillem sent a patch without underscore upstream. I've heard an independent suggestion to use an underscore from GCC upstream, so it seems underscore might well end up in this triplet. Note that the amd64 triplet already uses an underscore (in the CPU part though): x86_64-linux-gnu, so I don't think the presence of underscore should be a new technical issue introduced by armhf. It's probably up to the GCC upstream folks to decide on this. (Just been reminded on IRC): also, in discussion with two of those gcc folks in Cambridge (Ramana and Richard) and Wookey on Friday, we sort-of agreed on a base architecture level for arm-linux-gnueabihf. Although *technically* it's possible to use armhf on v5 and v6, there's not a huge amount of point. So the right answer is to make arm-linux-gnueabihf imply v7, with vfp3-d16. (/me waits for somebody to come along and correct his faulty memory now...) -- Steve McIntyre, Cambridge, UK.st...@einval.com Is there anybody out there? -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110314151821.gd19...@einval.com
Re: Bug#594179: dpkg armhf patch acceptance status?
Hello, 2011/2/21 Jonathan Nieder jrnie...@gmail.com: That leaves two remaining questions: - can each Debian arch have a distinct toolchain? If not, why not (since it would be very convenient to use)? The short answer seem to be no, GCC upstream does not like the idea to have different triplets for those architectures, extending libc triplet value to encode calling conventions. If I understand correctly that is what dpkg maintainers would like to see. - how do we communicate distinct compiler flags for the build and host machines to packages, with a minimum of disruption to existing packaging? Maybe dpkg-buildflags needs to distinguish between --build and --host flags, so that dh_auto_configure et al can pass HOST_CFLAGS to configure. Yet another thought, Debian architecture maps to MAtuples, which then sets defaults on the toolchain via specs file. Does it change something if we use (armel) libgcc1 with armhf specs file, rather than have a libgcc1 defaulting for armhf at (cross-)build time? Best regards, -- Héctor Orón Our Sun unleashes tremendous flares expelling hot gas into the Solar System, which one day will disconnect us. -- Day DVB-T stop working nicely Video flare: http://antwrp.gsfc.nasa.gov/apod/ap100510.html -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTi=z-nyr4dpc+0eokpfrdusz2eueadsgwobb8...@mail.gmail.com
Re: Bug#594179: dpkg armhf patch acceptance status?
On Tue, Feb 22, 2011 at 01:20:03AM +, Hector Oron wrote: Yet another thought, Debian architecture maps to MAtuples, which then sets defaults on the toolchain via specs file. Does it change something if we use (armel) libgcc1 with armhf specs file, rather than have a libgcc1 defaulting for armhf at (cross-)build time? $ objdump -T /lib/libgcc_s.so.1 |grep div 3c9c gDF .text 020c GCC_3.0 __divdf3 3c9c gDF .text 020c GCC_3.5 __aeabi_ddiv 788c gDF .text 0448 GLIBC_2.0 __udivdi3 63e8 gDF .text 07a8 GCC_4.0.0 __divdc3 2ee0 gDF .text 012c GCC_3.0 __divsi3 2ec8 gDF .text 0018 GCC_3.5 __aeabi_uidivmod 300c gDF .text 0018 GCC_3.5 __aeabi_idivmod 2ee0 gDF .text GCC_3.5 __aeabi_idiv 45c0 gDF .text 0160 GCC_3.5 __aeabi_fdiv 45c0 gDF .text 0160 GCC_3.0 __divsf3 6ecc gDF .text 04ac GLIBC_2.0 __divdi3 2dcc gDF .text 00fc GCC_3.0 __udivsi3 811c gDF .text 0550 GCC_3.0 __udivmoddi4 2dcc gDF .text GCC_3.5 __aeabi_uidiv 49ec gDF .text GCC_3.5 __aeabi_uldivmod 5ec0 gDF .text 0528 GCC_4.0.0 __divsc3 49d0 gDF .text GCC_3.5 __aeabi_ldivmod $ Probably? :) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Bug#594179: dpkg armhf patch acceptance status?
+++ Guillem Jover [2011-02-18 11:13 +0100]: Guillem makes some good points about how GNU triplets should (and once did) represent ABIs, and that if they still did, dpkg (and everything else) could use them as the definitive ABI-indicator. He's quite right. _Something_ has to stand as nomenclature for the ABI. It could equally well be GNU triplets or Multiarch Tuples. I'm quite happy for either to be used. Multiarch directories could use triplets under those circumstances and there would be no need for the new tuples. But it is also the case that a given toolchain can produce binaries of different ABIs, so there is logic in the GCC argument that the triplet denotes a toolchain, not (necessarily) an ABI. (e.g arm-linux-gnueabi toolchain can produce armel and armhf binaries (and in fact there are more incompatible ABIs it could spit out, but we're not trying to make distros out of those). It makes sense to me that, these days, a triplet represents a toolchain, and an MAtuple an ABI. If there was a 1-1 mapping between these things then triplets would suffice, but there isn't. So it seems to me, that we either have to persuade GCC to go back to one triplet per ABI or we need to adopt the proposed Tuples. It is logically neater in many ways to go back to one-triplet-per-ABI, but like Steve, I'm not optimistic about this being ultimately acceptable to upstream or that it could be done in a sensible period of time. Starting again with a properly defined list and some rules about new identifiers lets us get it right this time, and arrange for it to stay right in the future. So what happens if we do this? Let's look at some examples mentioned so far: * I think it's important to be able to consistently support co-installing different default cross-compilers for different ABIs which would otherwise share the same triplet. And while we could avoid the problem for multiarch libraries co-installations by using the multiarch tuples, we would not be able to avoid it for the cross-compilers. This is true, but in fact the arm-linux-gnueabi and arm-linux-gnuhf toolchains would be the same apart from their libgcc and default options (spec file). A multilib build of this toolchain, supporting both options, would work for targetting both ports, but we do still lack a good way of switching spec files to change the default target (which would be useful for all sorts of reasons). * The assumption that each GNU triplet denotes a different ABI is so entrenched in the GNU build system, that we have things like the following all over the place to properly support cross-building: ,--- ifeq ($(DEB_BUILD_GNU_TYPE), $(DEB_HOST_GNU_TYPE)) confflags += --build $(DEB_HOST_GNU_TYPE) else confflags += --build $(DEB_BUILD_GNU_TYPE) --host $(DEB_HOST_GNU_TYPE) endif `--- This would not hold true any longer if we didn't use a unique triplet per arch, and would thus break in quite annoying ways. Yes, this is potentially a pain in the bum. We need to select a toolchain (which could be 'arm-linux-gnueabi' for both arm port targets, but with different default options and a different default linker and include paths). I haven't yet worked out how those will be selected, as currently they are built-in to the cross-compiler and referring to it by name sets them implicictly. debian/rules has access to the -aDEB_HOST_ARCH which allows the necessary discrimiation, and automatically supplies the /etc/dpkg-cross/cross-config.DEB_HOST_ARCH autoconf values, which may be sufficient, along with config.guess. There are a lot of instances of -L /usr/DEB_HOST_GNU_TYPE/lib which need fixing for multiarch anyway, so even if we have unique GNU triplets, work will be needed in lots of packages to make cross-building work again. Anything which already relies on default compiler paths should work fine. If using non-unique toolchain triplets, we need a robust mechanism for host ABI selection within the multilibs available. * Ignoring the bi-directional 1:1 mapping would be a PITA, as it implies not being able to automatically bootstrap dpkg on a new port or dpkg package builds on foreign distros. The former is annoying but not done frequently, the latter is going to be a problem for each non-dpkg based distribution, as they'll have to bootstrap dpkg on each arch where dpkg is built anew. It ends up being a matter of off-loading the knowledge of the arch and build system from the dpkg/gcc combo to the porters/maintainers, which seems rather unappealing. I don't think I understand this point. Who are these people that build dpkg on non-dpkg distro, and why will they have harder bootstraping? The toolchain has the same triplet for binary incompatible producing objects, which seems like a bug/misfeature to me, and that's one of the assumptions dpkg-dev has relied on, in the same way as multiarch when deciding to use the triplet as a unique token for the
Re: Bug#594179: dpkg armhf patch acceptance status?
(-cc: the bug because I have nothing major to add at the moment. Please cc me on replies.) Wookey wrote: Guillem makes some good points about how GNU triplets should (and once did) represent ABIs, and that if they still did, dpkg (and everything else) could use them as the definitive ABI-indicator. He's quite right. [...] But it is also the case that a given toolchain can produce binaries of different ABIs, so there is logic in the GCC argument that the triplet denotes a toolchain, not (necessarily) an ABI. (e.g arm-linux-gnueabi toolchain can produce armel and armhf binaries (and in fact there are more incompatible ABIs it could spit out, but we're not trying to make distros out of those). Thanks for this explanation! It helps a lot. That leaves two remaining questions: - can each Debian arch have a distinct toolchain? If not, why not (since it would be very convenient to use)? ifeq ($(DEB_BUILD_GNU_TYPE), $(DEB_HOST_GNU_TYPE)) confflags += --build $(DEB_HOST_GNU_TYPE) else confflags += --build $(DEB_BUILD_GNU_TYPE) --host $(DEB_HOST_GNU_TYPE) endif [...] Yes, this is potentially a pain in the bum. We need to select a toolchain (which could be 'arm-linux-gnueabi' for both arm port targets, but with different default options - how do we communicate distinct compiler flags for the build and host machines to packages, with a minimum of disruption to existing packaging? Maybe dpkg-buildflags needs to distinguish between --build and --host flags, so that dh_auto_configure et al can pass HOST_CFLAGS to configure. Jonathan -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110221020955.GB29661@elie
Re: Bug#594179: dpkg armhf patch acceptance status?
On Sun, Feb 20, 2011 at 08:10:06PM -0600, Jonathan Nieder wrote: That leaves two remaining questions: - can each Debian arch have a distinct toolchain? If not, why not (since it would be very convenient to use)? By virtue of the fact that each architecture will have its own copy of gcc in the archive, as an Architecture: any package with different defaults built in, each architecture does have a distinct toolchain. The problem really only arises when you want to use a cross-compiler for the architecture; dpkg-architecture only gives packages the DEB_HOST_GNU_TYPE information to work with, which is no longer sufficient to ensure packages are being correctly built for the stated target arch. I.e., you can invoke the compiler as arm-linux-gnueabi-gcc, but you don't know if that's going to output binaries for armel or for armhf. ifeq ($(DEB_BUILD_GNU_TYPE), $(DEB_HOST_GNU_TYPE)) confflags += --build $(DEB_HOST_GNU_TYPE) else confflags += --build $(DEB_BUILD_GNU_TYPE) --host $(DEB_HOST_GNU_TYPE) endif [...] Yes, this is potentially a pain in the bum. We need to select a toolchain (which could be 'arm-linux-gnueabi' for both arm port targets, but with different default options - how do we communicate distinct compiler flags for the build and host machines to packages, with a minimum of disruption to existing packaging? Maybe dpkg-buildflags needs to distinguish between --build and --host flags, so that dh_auto_configure et al can pass HOST_CFLAGS to configure. I think it will be disruptive any which way you cut it, if the goal is to have dpkg provide this information. If we instead make it the problem of the cross-compiling developer to ensure their toolchain has the right defaults for their target architecture, we don't need to worry about package disruption at all... we just have to worry about people using the wrong toolchain settings for their architecture. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Bug#594179: dpkg armhf patch acceptance status?
+++ Steve Langasek [2011-02-18 17:36 -0800]: * The remaining problem at least for multiarch is the use of more specialized cpu names for the i386 triplets, i486-linux-gnu on Debian, which might change depending on the base instruction set to support, for example i686-linux-gnu on Ubuntu. Due to #611741, it already crossed my mind (but removed it from the list of solutions before sending the reply as at the time it seemed slighly preposterous just to fix the divergence with Ubuntu) that we should switch back our i386 arch to use i386 as the base cpu name for the triplet (i386-linux-gnu) in the same way we use it in other arches, like on arm where we use arm-linux-gnu instead of something like armv4tel-linux-gnueabi, for example. (I mentioned this already to Steve and Raphaël on some private conversation.) The challenge, as Matthias points out, is that these triplets are already so entrenched and there is so much software that handles x86 specially - even if incorrectly! - that it's prohibitive to switch back to i386-linux-gnu as our triplet because of all the re-porting work we'll have to do to get properly functioning packages on x86. I know little of x86 world, but are we sure this is more work than the fixing-up we'll need to do in many packages to properly deal with multiple available ABIs within a toolchain, and making the new MAtuples be used correctly everywhere? (especially when cross-building, for both matters). The underlying intent of the tuples proposal is that we stop pretending that GNU triplets provide a valid global one-to-one mapping to ABIs, because we know from several concrete, high profile examples that this is not true. You have proposed a patch that Matthias has said looks ok, but if he adds it to the Debian/Ubuntu gcc, that only solves the problem for Debian and Ubuntu. Multiarch is intended as a cross-vendor standard, fixing the FHS's inadequate libqual directories and providing binary interoperability for anyone choosing to implement it. How can we achieve that if we're using strings in our paths that are dependent on distro-specific patches? Do we expect to tell other implementors they have to use our GCC? The multiarch tuple proposal would externalize this problem by establishing a central, standard, one-to-one mapping between ABIs and strings *for this precise purpose*. I agree that this establishment of a generic FHS multiarch library path standard is the right thing (TM), and that it's no good if it can't be done upstream . But equally Guillem is right that ABI-sepecific triplets could do that job too (and with less change to existing practice overall). Given that there is no consensus that this is even a bug to be fixed, I am not content to have multiarch blocked indefinitely on getting triplet fixes propagated upstream; nor am I happy to have multiarch paths tied to distro-specific implementation details. Are you going to do the heavy lifting to get these changes accepted by GCC upstream? How long do you think that will take, and at what point would you decide that you're not getting anywhere and fall back to diverging from upstream for multiarch? This is the nub of the practical problem. I've rather firmly committed to getting initial multiarch support landed in the 11.04 Ubuntu release. If we can (collectively) get our decision made on the path selection *now*, that's achievable - and we can be rid of ia32-libs from Debian (unstable) and Ubuntu within a year, and we can bring armhf up as the first multiarch-from-the-start port in Debian. If we instead let ourselves get drawn into open-ended discussions trying to persuade GCC upstream that we're right about triplets and they're wrong, it may be years longer before we see any multiarch implementation at all. Remember that we were discussing multiarch before sarge was released - I don't want to still be discussing it after wheezy is out. :( I guess I missed the first 3-odd years of this debate. I'm assuming we've already tried reasonably hard persuading the GCC people on this point? Unless the feature of being able to separately specify toolchains (triplets) and ABIs (tuples) is important (and it may be for biarch/triarch arches, but I'm not yet convinced), then given the extreme similarity of tuples and triplets, it does seem like ABI-specific triplets would be a 'better' solution to this problem than inventing a new set; and in general Debian likes to go for the technically-best solutions even if it takes longer. (Multiarch in general is an example of this). However, equally, it's taken a really long time to get this far, and if we made a reasonable effort to get GCC people to agree with guilem's view of the world, but failed, then I'm happy that the expediency of the new tuples is justified. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email
Re: Bug#594179: dpkg armhf patch acceptance status?
[ Sorry for entangling the armhf bug with the i386 stuff, subsequent
replies should probably remove debian-arm and the bug report from
them. ]
On Fri, 2011-02-18 at 13:30:19 +0100, Matthias Klose wrote:
On 18.02.2011 11:13, Guillem Jover wrote:
[ CCing Matthias, as I'd like your opinion on my proposed solution
involving some Debian gcc changes. ]
The armhf patch for gcc looks ok, however I would like to see this
better addressed in Linaro and/or upstream.
Ok, I'll run it through upstream to see what they say. I just wanted
to check if you'd be fine including it regardless of upstream's stance
on it, to at least be able to decide on the armhf triplet issue, the
multiarch paths decision would be unrelated to this then.
Yes but x86 goes to the other extreme, with separate triplets for
compatible ABIs ({i386,i486,i586,i686}-linux-gnu); the fact is the
triplet is not a good ABI specifier.
Sure, but as mentioned above, I'm now convinced the correct solution is
to switch back to i386-linux-gnu.
No, this doesn't work. the triplet currently is set to
i586-linux-gnu. Switching back to to i386 would loose the sync
primitives and a not working gomp. There is too much relying on =
i586 in many configure's of other packages.
Oh, I think this actually strengthens my point!
The gcc-4.4:i386 package seems to be compiled on Debian to target i586
as the base instruction set, as can be seen in its debian/rules2:388,
which implies changing the triplet would not affect this (barring the
small change I'm attaching a patch for, untested), and thus the sync
primitive and gomp would be fine (at least from my understanding of
the gcc build system). And just to make this perfectly clear, I'm
not proposing to downgrade the actual instruction set base line.
So while the base instruction set was changed to i586 in gcc 4.4.0-1~exp1
it did not switch the GNU triplet to i586-linux-gnu to match:
$ dpkg --print-architecture
i386
$ gcc-4.4 -dumpmachine
i486-linux-gnu
$ gcc-4.5 -dumpmachine
i486-linux-gnu
$ gcc-4.6 -dumpmachine
i486-linux-gnu
$ grep ^i386 /usr/share/dpkg/cputable|tr -s '\t '|cut -f2
i486
So I don't see how any debian/rules could be currently relying on
the i586-linux-gnu triplet (as long as they set them correctly through
the dpkg-architecture variables, coming from gcc, and not from
config.guess).
Also having to transition all our packaging to the new triplet every
time i386 changes the base line does not seem right, and it's
something we don't do on any of the other architectures. I'd even say
it's just wrong, packages should either use the default compiler base
instruction set, set their required one independenly of it, do
multiple builds and use hwcaps for libraries or do run time detection.
Given the above we'd need to either switch to i586-linux-gnu or
i386-linux-gnu, it seems to me both will imply the same amount of
changes? And thus going for the latter seems the correct solution,
it matches with the other architectures, can be used as the multiarch
paths and can reduce some divergence with Ubuntu, all of them a clear
win! :)
Not only for the good, as the switch in Ubuntu to i686 did show,
because many configure files assume sse with i686-linux-gnu.
I'd say any such assumption in those packages is buggy, per above.
thanks,
guillem
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110221063219.ga22...@gaara.hadrons.org
Re: Bug#594179: dpkg armhf patch acceptance status?
On Mon, Feb 21, 2011 at 02:22:44AM +, Wookey wrote: The challenge, as Matthias points out, is that these triplets are already so entrenched and there is so much software that handles x86 specially - even if incorrectly! - that it's prohibitive to switch back to i386-linux-gnu as our triplet because of all the re-porting work we'll have to do to get properly functioning packages on x86. I know little of x86 world, but are we sure this is more work than the fixing-up we'll need to do in many packages to properly deal with multiple available ABIs within a toolchain, and making the new MAtuples be used correctly everywhere? (especially when cross-building, for both matters). multiple available ABIs within a toolchain is not a problem that has to be solved on x86 today, so yes, it is more work. On x86 we do have at least one tuple identifier for each ABI - we just have the problem that we have /too many/ of them available on x86. But while multilib toolchains are definitely of interest on x86 (-m32/-m64), each of these ABIs also have a distinct tuple associated with them (x86_64-linux-gnu, in86-linux-gnu). You have proposed a patch that Matthias has said looks ok, but if he adds it to the Debian/Ubuntu gcc, that only solves the problem for Debian and Ubuntu. Multiarch is intended as a cross-vendor standard, fixing the FHS's inadequate libqual directories and providing binary interoperability for anyone choosing to implement it. How can we achieve that if we're using strings in our paths that are dependent on distro-specific patches? Do we expect to tell other implementors they have to use our GCC? The multiarch tuple proposal would externalize this problem by establishing a central, standard, one-to-one mapping between ABIs and strings *for this precise purpose*. I agree that this establishment of a generic FHS multiarch library path standard is the right thing (TM), and that it's no good if it can't be done upstream . But equally Guillem is right that ABI-sepecific triplets could do that job too (and with less change to existing practice overall). Multiarch is a significant departure from existing practice one way or the other. I think the question of whether we maintain our ABI string list as a delta against GNU triplets or as an entirely separate standard is really quite a minor detail in comparison. I guess I missed the first 3-odd years of this debate. I'm assuming we've already tried reasonably hard persuading the GCC people on this point? In the x86 case, it's not something that GCC people can fix. The overloading of GNU triplets on x86_32 is now a well-entrenched practice throughout the community, and neither they nor we can fix by fiat the consequences of changing our triplet - only by a lot of hard work. In the armhf case there was an upstream mailing list discussion, from which the only emerging consensus (to the extent we can say there was one) was that the official GNU triplet should stay the same. This mailing list discussion informed the BoFs we had at DebConf about multiarch tuples, and I think it qualifies as tried reasonably hard. It's hard enough for my purposes, because I'm not out to try to dictate policy to the GCC maintainers, so when they say that's not what triplets mean, I greatly prefer finding a path of lesser resistance. I thought we had that with the multiarch tuples proposal, but maybe not. :/ Unless the feature of being able to separately specify toolchains (triplets) and ABIs (tuples) is important (and it may be for biarch/triarch arches, but I'm not yet convinced), then given the extreme similarity of tuples and triplets, it does seem like ABI-specific triplets would be a 'better' solution to this problem than inventing a new set; and in general Debian likes to go for the technically-best solutions even if it takes longer. (Multiarch in general is an example of this). I don't see either of these to be technically better or worse. The fact is that we are going to *have* to document multiple points where our directory strings do not follow naturally from the existing array of GNU triplets; and that documentation needs to be maintained in a readily consumable fashion. Given those constraints, I don't think that using a modified set of GNU triplets is any better than creating new strings from scratch. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: dpkg armhf patch acceptance status?
On 18 February 2011 06:27, Luke Kenneth Casson Leighton l...@lkcl.netwrote: ... and in the meantime, markos is under pressure to manually maintain everything _without_ a delta-management tool, which puts ongoing and ever-increasing pressure on what he can reasonably handle, whilst those discussions are underway. re-read what he wrote. he's effectively asking that the dpkg patch (which isn't acceptable as it stands) be hurried up, because he's got a ton of stuff that's being added to daily, piling up behind it. I appreciate that you are worrying about the pressure I'm under, but I'll handle it, it's not that bad. Things have become much smoother, the patches are in the BTS, next week we'll do porterNMUs for the unfixed packages, and the only thing I really worry about is java support and d-i armhf integration. We're already in the 87% of the archive and the todo list gets shorter all the time. Anyway, please feel free to take some time off and work on a PoC for what you mean, if you're afraid that people don't understand your words, you can be certain that they'll understand your code. Until then, I really find this discussion pointless. Konstantinos
Re: dpkg armhf patch acceptance status?
On Fri, Feb 18, 2011 at 04:27:52AM +, Luke Kenneth Casson Leighton wrote: precisely. this is another, (clearer or at least different) way of stating what i've been advocating. by having such a delta-maintaining tool, complex sets of deltas can be maintained indefinitely, or in fact completely reworked. We dont *want* to maintain deltas. If we start maintaining deltas, we are no longer Debian, we are a fork. Lets end this discussion now. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110218095330.ga25...@afflict.kos.to
Re: Bug#594179: dpkg armhf patch acceptance status?
[ CCing Matthias, as I'd like your opinion on my proposed solution involving some Debian gcc changes. ] Hi! On Thu, 2011-02-17 at 12:27:30 +0100, Loïc Minier wrote: Trying to kick the dust a bit as having the triplet in the air is kind of an unhappy situation for armhf :-) I think it's fair to assume several of you have already peeked into the notes I circulated on IRC the other day, :) I'm reincluding them here although slightly redacted and extended, for the benefit of the rest of the people. I'll still reply to specific points you rised below. GNU triplets * gcc upstream claims GNU triplets do not fully encode ABI: - Thus cannot be used properly to map deb arch ←→ GNU triplet. - Thus cannot be used for multiarch paths. - Thus cannot be used for default cross-toolchains sharing GNU triplet. - Thus we'd need yet another ABI encoding and mapping for multiarch and dpkg arches, instead of being able to just use GNU triplets. The one being currently proposed can be found at http://wiki.debian.org/Multiarch/Tuples. * But the GNU triplets have always encoded the ABI, it's even extremely explicit in some cases, for example with the arm EABI, executable formats (elf, aout, ecoff, etc) or stuff like powerpc-*-eabispe* or powerpc-*-eabialtivec* (supported by gcc upstream). * And we already use GNU triplets for powerpcspe (powerpc-linux-gnuspe) and lpia (i386-linux-gnulp) arches, and these do not need gcc upstream support as are handled transparently by the -gnu* patterns, and any differing ABI options are selected by the Debian gcc packaging. * There's other gcc options which can change the ABI of the default compiler besides the --with-float one, like --with-long-double-128, etc, and still they are not a problem mainly for two reasons: 1) In case they do not need to coexist, they can be handled like other transitions, like it was done in Debian, by renaming shared library packages or with versioned symbols and handling both ABIs at the same time. 2) No one seems to have needed to create coexisting default toolchains with diverging ABI options at the same time until now, or they have done so privately. * I think it's important to be able to consistently support co-installing different default cross-compilers for different ABIs which would otherwise share the same triplet. And while we could avoid the problem for multiarch libraries co-installations by using the multiarch tuples, we would not be able to avoid it for the cross-compilers. * The assumption that each GNU triplet denotes a different ABI is so entrenched in the GNU build system, that we have things like the following all over the place to properly support cross-building: ,--- ifeq ($(DEB_BUILD_GNU_TYPE), $(DEB_HOST_GNU_TYPE)) confflags += --build $(DEB_HOST_GNU_TYPE) else confflags += --build $(DEB_BUILD_GNU_TYPE) --host $(DEB_HOST_GNU_TYPE) endif `--- This would not hold true any longer if we didn't use a unique triplet per arch, and would thus break in quite annoying ways. For further details why that's needed check the autotools-dev section “Calling GNU configure properly” in its README.Debian. * Ignoring the bi-directional 1:1 mapping would be a PITA, as it implies not being able to automatically bootstrap dpkg on a new port or dpkg package builds on foreign distros. The former is annoying but not done frequently, the latter is going to be a problem for each non-dpkg based distribution, as they'll have to bootstrap dpkg on each arch where dpkg is built anew. It ends up being a matter of off-loading the knowledge of the arch and build system from the dpkg/gcc combo to the porters/maintainers, which seems rather unappealing. * Other packaging systems seem to not have made quite the same assumption about the GNU triplet as dpkg/Debian does. Gentoo's portage at least relies on the GNU triplet being unique per different arch as itseems to be using it on the path somehow. rpm and conary for example use uname which is not enough by itself, and quite unsatisfactory as it's lacking quite a bit of the ABI information, which probably has not presented as a problem for them as they do not have the amount of supported arches as Debian does, neither do they seem to have the same amount of mixes/convinations we do. So the other approaches seem to be actually inferior. * The remaining problem at least for multiarch is the use of more specialized cpu names for the i386 triplets, i486-linux-gnu on Debian, which might change depending on the base instruction set to support, for example i686-linux-gnu on Ubuntu. Due to #611741, it already crossed my mind (but removed it from the list of solutions before sending the reply as at the time it seemed slighly preposterous just to fix the divergence with Ubuntu) that we should switch back our i386 arch to use i386 as the base cpu name for
Re: Bug#594179: dpkg armhf patch acceptance status?
On 18.02.2011 11:13, Guillem Jover wrote:
[ CCing Matthias, as I'd like your opinion on my proposed solution
involving some Debian gcc changes. ]
The armhf patch for gcc looks ok, however I would like to see this better
addressed in Linaro and/or upstream.
Yes but x86 goes to the other extreme, with separate triplets for
compatible ABIs ({i386,i486,i586,i686}-linux-gnu); the fact is the
triplet is not a good ABI specifier.
Sure, but as mentioned above, I'm now convinced the correct solution is
to switch back to i386-linux-gnu.
No, this doesn't work. the triplet currently is set to i586-linux-gnu. Switching
back to to i386 would loose the sync primitives and a not working gomp. There
is too much relying on = i586 in many configure's of other packages. Not only
for the good, as the switch in Ubuntu to i686 did show, because many configure
files assume sse with i686-linux-gnu.
Matthias
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d5e665b.1060...@debian.org
Re: bootstrapping debian was: dpkg armhf patch acceptance status
+++ Riku Voipio [2011-02-18 11:53 +0200]: On Fri, Feb 18, 2011 at 04:27:52AM +, Luke Kenneth Casson Leighton wrote: precisely. this is another, (clearer or at least different) way of stating what i've been advocating. by having such a delta-maintaining tool, complex sets of deltas can be maintained indefinitely, or in fact completely reworked. We dont *want* to maintain deltas. If we start maintaining deltas, we are no longer Debian, we are a fork. Lets end this discussion now. Very succincly put. There is nothing wrong with the idea of using bitbake to bootstrap Debian, except that what you end up with is a set of fixes outside the Debian packaging. Even though it is harder and slower, I believe it a better long-term solution to do whatever it takes to get those fixes inside the packaging (or upstream, as appropriate). I have been doing a fair amount of research, thinking, discussion and documentation on this over the last couple of months, and intend to do some finalising and proper implementing of that next week. I have refrained from writing long emails about the reasoning and practicialities of this because I was expecting to be able to have the discussion in person next week. Unfortunately luke won't be there to have the argument in person, but I hope even he'd agree that the 'best' solution is to do it in Debian proper. It is true that this work only fixes the problem at hand (cyclic dependencies, bootstraping staged builds, bootstrap sequencing and cross-building the axiomatic set of base-node packages); it does not provide a generic mechanism for layering a patch set over Debian sources. Both OE and the emdebian tools provide such mechanisms, and that concept is useful for all sorts of reasons in the real world. I'd like to do more work on this idea in the future so that it was relatively easy to do. But it's really important to understand that you should only be using such mechanisms because it's expedient, and appropriate for your circumstances. It's not something that is appropriate for solving _Debian's_ problems. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110218133423.gd22...@dream.aleph1.co.uk
Re: bootstrapping debian was: dpkg armhf patch acceptance status
On Fri, Feb 18, 2011 at 1:34 PM, Wookey woo...@wookware.org wrote:
There is nothing wrong with the idea of using bitbake to bootstrap
Debian, except that what you end up with is a set of fixes outside the
Debian packaging.
there are clear reasons for why that has to be the case, which we've
gone over before.
Even though it is harder and slower, I believe it a
better long-term solution to do whatever it takes to get those fixes
inside the packaging (or upstream, as appropriate).
the problem with that is that when you have a long-term series of
changes which can only be *considered* for inclusion once they are
all, entirely, complete, ready, done, dusted, reviewed and proven to
work.
the armhf port is just _one_ example which meets that exact criteria.
I have refrained from writing long emails about the reasoning and
practicialities of this because I was expecting to be able to have the
discussion in person next week. Unfortunately luke won't be there to
have the argument in person,
nope. don't want arguments / discussions in an environment where the
sponsors, genesi usa, would quite likely be happy if i was dead.
but I hope even he'd agree that the
'best' solution is to do it in Debian proper.
yyup, definitely. perhaps suggesting a tool such as bitbake was
_necessary_ to galvanise you, wookey, and others, to consider such.
if you're serious about ensuring that extra patches are contained
within debian infrastructure, the idea that occurred to me, just last
night, was to have a per-architecture patches directory.
debian/patches.{archname} for example.
the trouble with _that_ is that it requires that, again, the patches
be accepted by the debian maintainer!
[we've _been_ over this (2 months ago), riku, et al].
individual debian maintainers might simply choose, on a whim, to
completely ignore individual per-arch or per-project patches, thus
totally undermining efforts to develop a particularly long-term
complex and self-consistent, self-referring set of developments [that
must, always will be intended for going *into* debian NOT being
maintained separately as a fork]
deltas-on-deltas *WITHIN* the debian infrastructure, creating tools
that are based on DEBIAN. perhaps those tools might choose to
leverage the power of bitbake AS A TOOL, WORKING WITHIN DEBIAN AND
SUITED TO DEBIAN AND HAVING NOTHING TO DO WITH OPENEMBEDDED
DISTRIBUTION, perhaps they might not.
so.
riku.
if you dictate this discussion is at an end, because this sounds
like a debian forking tool, then there will be no way for anyone
involved with debian to work *collaboratively* on significant complex
long-term strategic changes that will end up being *in* debian NOT
repeat NOT i repeat NOT i repeat, again, with respect, NOT a fork *OF*
debian.
is that what you're saying? if so, please confirm and state
explicitly that it is your wish and intent to restrict and curtail
debian's future development, and that you are happy for the present
situation to persist.
if i have misunderstood your intent, i sincerely apologise, please do
clarify and perhaps aid the debian project by engaging in a discussion
which provides the project with the benefit of your experience and
creativity, to solve this particular strategic challenge.
l.
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/AANLkTi=mw_duhvmgfnktqxevseuutv4yengzveave...@mail.gmail.com
Re: bootstrapping debian was: dpkg armhf patch acceptance status
On 18 February 2011 16:31, Luke Kenneth Casson Leighton l...@lkcl.netwrote: nope. don't want arguments / discussions in an environment where the sponsors, genesi usa, would quite likely be happy if i was dead. No, we just disagree. This is very unjust to say, and anyway, we're just ONE of the sponsors and not even the main one for this particular event (Debian, ARM and Toby Churchill being the other sponsors). Konstantinos
Re: bootstrapping debian was: dpkg armhf patch acceptance status
On Fri, Feb 18, 2011 at 2:56 PM, Konstantinos Margaritis mar...@genesi-usa.com wrote: On 18 February 2011 16:31, Luke Kenneth Casson Leighton l...@lkcl.net wrote: nope. don't want arguments / discussions in an environment where the sponsors, genesi usa, would quite likely be happy if i was dead. No, we just disagree. noo, markos, it's much stronger than that. i've sent you privately a copy of the message sent by bill, the CEO of genesi-usa (on the basis that it was sent to 20 others i believe it reasonably to send to you privately but definitely not to this list). genesi usa employees went BALLISTIC when i called matt out on his behaviour on the fedora-arm list, when all i was doing was asking why - and PRIVATELY asking them why - from a business perspective, i should introduce them to business deals which, unless matt was reined in, could be jeopardised by his behaviour if he continued with the same attitude that he displayed on the list? there was absolutely nothing unreasonable nor even _remotely_ inflammatory about the approach that i took, yet matt _still_ chose to focus, instead of on the business opportunity, on proving himself technically superior. given that genesi-usa is, as you can see from that private message, critically dependent upon matt for technical knowledge, genesi usa's CEO is placed in an unenviable and difficult position of having to side with this particular employee. strategically, the best way to do that is to treat _me_ as the one who is wrong, wrong, wrong, alienated, persona non-grata, (and, preferably, albeit i realise this is completely overstating the case - dead). can we drop this now please? l. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimhbrnwutqnrujowaeuwu3ngen16ohppw+g9...@mail.gmail.com
Re: bootstrapping debian was: dpkg armhf patch acceptance status
On 18 February 2011 17:10, Luke Kenneth Casson Leighton l...@lkcl.netwrote: can we drop this now please? Definitely.
Re: Bug#594179: dpkg armhf patch acceptance status?
On Fri, Feb 18, 2011 at 01:30:19PM +0100, Matthias Klose wrote: On 18.02.2011 11:13, Guillem Jover wrote: [ CCing Matthias, as I'd like your opinion on my proposed solution involving some Debian gcc changes. ] The armhf patch for gcc looks ok, however I would like to see this better addressed in Linaro and/or upstream. I'm not sure how Linaro could better address this, short of persuading upstream to allocate a separate triplet for armhf - which has been explicitly refused on the upstream mailing list. Do you have something else in mind here? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Bug#594179: dpkg armhf patch acceptance status?
Hey
Trying to kick the dust a bit as having the triplet in the air is
kind of an unhappy situation for armhf :-)
On Wed, Sep 08, 2010, Guillem Jover wrote:
We currently need something like this in dpkg-dev because the mappings
need to be bidirectional, as dpkg-dev needs to be able to convert
from GNU triplet to Debian architecture and the other way around.
Steve wondered why this is the case, and that's because for
cross-compiling purposes dpkg-architecture infers the host architecture
from the CC environment variable through the -dumpmachine option.
Chaning this is possible but, would break a current way of
cross-compiling which has been around for a long time.
So this use case is CC=arm-linux-gnueabi-gcc dpkg-buildpackage and it
just guesses the -a flag that you should have set?
The toolchain has the same triplet for binary incompatible producing
objects, which seems like a bug/misfeature to me, and that's one of
the assumptions dpkg-dev has relied on, in the same way as multiarch
when deciding to use the triplet as a unique token for the installation
directories.
You describe this as a bug/misfeature, that might be true but I don't
think we can challenge this usage of triplets in the upstream
toolchain, and multiarch is moving to having its own tuples instead now
(http://wiki.debian.org/Multiarch/Tuples).
This also causes issue with not being able to have installed two
cross-toolchains for say armel and armhf as they share triplet,
although you can use the armel toolchain with few options to build for
armhf, but then you'd need to specify those as part of the CC variable.
Even if we could co-install them, I'm not sure how
/some-armel-path/arm-linux-gnueabi-gcc and
/some-armhf-path/arm-linux-gnueabi-gcc could helpfully be installed on
the same system :-/
It's a real limitation of the upstream toolchain.
Also that also happens with biarch, you can produce i386 binaries from
an x86_64 toolchain, yet they both have their own triplet.
Yes but x86 goes to the other extreme, with separate triplets for
compatible ABIs ({i386,i486,i586,i686}-linux-gnu); the fact is the
triplet is not a good ABI specifier.
Anyway, ideally I'd rather see this addressed by giving armhf a real
triplet, which would also make multiarch life way easier as there'd not
be any need to define an artificial set of neutral architecture names
to be able to place objects in the file system. But if this is not going
to happen, and thus the assumptions dpkg-dev is making have been just
wrong, then I'd rather drop the bidirectional mappings, and be done
with it. This will need careful consideration though, as it's breaking
a current interface, but something that could be done for dpkg 1.16.x.
Having a separate triplet (not using the vendor field) like e.g. lpia
would mean a lot of pain IMO, and we'd have to fix many packages to
cope with it, including reaching out to upstream etc. It was pain for
lpia for sure.
We could have an additional set of preprocessor macros which dpkg
checks for to decide which Debian architecture we're talking about; the
the would only be done if there is more than one architecture using the
same triplet in dpkg tables. This alone is a bit fragile though, as it
means that if a new ABI is introduced to an existing triplet and is not
immediately added as a new dpkg architecture, then people might be
picking the wrong dpkg architecture when using a toolchain defaulting
to thenew ABI.
I wonder whether it would be a good idea to use multiarch tuples
internally; dpkg would still have to map to/from GNU triplets, but it
would force implementors to think about their ABI. I am not sure how
we can ensure that we've mapped to the right tuple though. Neither am
I sure that the multiarch tuples are frozen already, so it might be too
early for that either.
Bye
--
Loïc Minier
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110217112730.ga19...@bee.dooz.org
Re: dpkg armhf patch acceptance status?
Loïc's latest post drew my attention back to this thread, where I see I had this message flagged for follow-up: On Fri, Sep 10, 2010 at 09:35:24AM +0200, Goswin von Brederlow wrote: I realize this is ideal, but: - there's been very strong upstream pushback on this, asserting that this is the correct triplet to use for both arm calling conventions, so if we require a distinct triplet for armhf (instead of using the vendor field), that's going to block any armhf port for quite a while (possibly indefinitely) - armhf was not the sole motivation for the proposal to define neutral architecture names; x86 was already a problem because of the changing triplets depending on which level of instruction set compatibility is targeted. *Both* of these examples show that GNU triplets are not defined in a way that they map directly to what we need for multiarch, so it's best to explicitly define our mapping externally. So even if you persuaded the upstream toolchain folks to specify a new triplet for armhf after all, I think we should still go ahead with a separate name mapping table for multiarch. Note that uclibc also suffers this problems. x86_64-linux-uclibc is in no way unique as different uclibc compile options create different ABIs all with the same tripplet. We have a draft proposal for tuples to use in the filesystem paths for multiarch: http://wiki.debian.org/Multiarch/Tuples uclibc is included in the design, with a single identifier of 'uclibc'. We probably need to have a better definition here. Where is the right place to raise this point for discussion in Debian? Should I bring this up on the debian-embedded list? Are there other stakeholders who would have input regarding the array of available uclibc ABIs and how to specify these? Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110217200306.gb11...@virgil.dodds.net
Re: dpkg armhf patch acceptance status?
On Tue, Sep 7, 2010 at 12:01 PM, Konstantinos Margaritis mar...@genesi-usa.com wrote: Hi all, I really would like to know the stance of the dpkg maintainers regarding the armhf dpkg patch. I have a ton of armhf patches that I'm waiting to file as bug reports, but without the dpkg patch, those patches would be useless, so I'm holding back, but that in the meantime increases the workload as newer packages appear all the time and I have to forward port the armhf patches all the time. konstantinous, this is PRECISELY why i advocate - and continue to advocate - a build system based around bitbake (NOT REPEAT NOT THE ENTIRE OPENEMBEDDED INFRASTRUCTURE AS ASSUMED BY SOME PEOPLE WHO THEN ASSUMED I WAS A F*G IDIOT FOR EVEN MENTIONING BITBAKE) the reason is plain and simple: patches-to-packaging such as the patch to dpkg you refer to can be applied easily by bitbake infrastructure prior to a build, in fact the entire debian packaging of dpkg and other packages that you are maintaining differences on can themselves be committed to a bitbake-compatible git repository, that git repository uploaded, managed, distributed and generally worked on by *other* people not just yourself; each set of patches-to-debian-packages, as they *are* accepted upstream can then be *dropped* from the git repository; and so on and so forth. there are damn good reasons why i mentioned and advocated the use of bitbake as both a package-development as well as a build AND a cross-build tool, precisely to help _you_ to cater for the exact circumstances in which debian developers now find themselves causing quite some awkwardness as the build progresses. perhaps, even, horror-of-horrors or hope-beyond-hope depending on which side of the fence you sit, such a system might even help to manage the scenario where large-scale en-masse changes could be planned, developed, made and reviewed to ubuntu packages, thus allowing ubuntu to actually be what it should have bloody well been in the first place: nothing more than an extra debian repository with overrides for certain packages. what stops that from being desirable let alone feasible is the fact that ubuntu is designed to be idiot-proof, thus only the idiots use it, and that keeps them the bloody hell away from debian, which is GREAT! :) l. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktineuwanracxggklgmludnwynge60p1xhhq9x...@mail.gmail.com
Re: dpkg armhf patch acceptance status?
Luke, 1. My name is Konstantinos, or Kostas, or if you prefer, just call me markos. It's not konstantinos, and it's not konstantinous. 2. My workload is big even without considering crazy solutions of distro-wide bitbake-integrations. If you so strongly believe that this method works so great, feel freel to demonstrate it by *proving* it works. Otherwise, it's just noise that distracts me from my work. I seem to remember someone famous saying sth like show the code or sth.. :P So, please don't hijack the thread and the bug report, with something totally irrelevant. Konstantinos (http://en.wikipedia.org/wiki/Constantine_%28name%29) On 17 February 2011 22:19, Luke Kenneth Casson Leighton l...@lkcl.netwrote: On Tue, Sep 7, 2010 at 12:01 PM, Konstantinos Margaritis mar...@genesi-usa.com wrote: Hi all, I really would like to know the stance of the dpkg maintainers regarding the armhf dpkg patch. I have a ton of armhf patches that I'm waiting to file as bug reports, but without the dpkg patch, those patches would be useless, so I'm holding back, but that in the meantime increases the workload as newer packages appear all the time and I have to forward port the armhf patches all the time. konstantinous, this is PRECISELY why i advocate - and continue to advocate - a build system based around bitbake (NOT REPEAT NOT THE ENTIRE OPENEMBEDDED INFRASTRUCTURE AS ASSUMED BY SOME PEOPLE WHO THEN ASSUMED I WAS A F*G IDIOT FOR EVEN MENTIONING BITBAKE) the reason is plain and simple: patches-to-packaging such as the patch to dpkg you refer to can be applied easily by bitbake infrastructure prior to a build, in fact the entire debian packaging of dpkg and other packages that you are maintaining differences on can themselves be committed to a bitbake-compatible git repository, that git repository uploaded, managed, distributed and generally worked on by *other* people not just yourself; each set of patches-to-debian-packages, as they *are* accepted upstream can then be *dropped* from the git repository; and so on and so forth. there are damn good reasons why i mentioned and advocated the use of bitbake as both a package-development as well as a build AND a cross-build tool, precisely to help _you_ to cater for the exact circumstances in which debian developers now find themselves causing quite some awkwardness as the build progresses. perhaps, even, horror-of-horrors or hope-beyond-hope depending on which side of the fence you sit, such a system might even help to manage the scenario where large-scale en-masse changes could be planned, developed, made and reviewed to ubuntu packages, thus allowing ubuntu to actually be what it should have bloody well been in the first place: nothing more than an extra debian repository with overrides for certain packages. what stops that from being desirable let alone feasible is the fact that ubuntu is designed to be idiot-proof, thus only the idiots use it, and that keeps them the bloody hell away from debian, which is GREAT! :) l.
Re: dpkg armhf patch acceptance status?
+++ Steve Langasek [2011-02-17 12:03 -0800]: Loïc's latest post drew my attention back to this thread, where I see I had this message flagged for follow-up: On Fri, Sep 10, 2010 at 09:35:24AM +0200, Goswin von Brederlow wrote: I realize this is ideal, but: - there's been very strong upstream pushback on this, asserting that this is the correct triplet to use for both arm calling conventions, so if we require a distinct triplet for armhf (instead of using the vendor field), that's going to block any armhf port for quite a while (possibly indefinitely) - armhf was not the sole motivation for the proposal to define neutral architecture names; x86 was already a problem because of the changing triplets depending on which level of instruction set compatibility is targeted. *Both* of these examples show that GNU triplets are not defined in a way that they map directly to what we need for multiarch, so it's best to explicitly define our mapping externally. So even if you persuaded the upstream toolchain folks to specify a new triplet for armhf after all, I think we should still go ahead with a separate name mapping table for multiarch. Note that uclibc also suffers this problems. x86_64-linux-uclibc is in no way unique as different uclibc compile options create different ABIs all with the same tripplet. We have a draft proposal for tuples to use in the filesystem paths for multiarch: http://wiki.debian.org/Multiarch/Tuples uclibc is included in the design, with a single identifier of 'uclibc'. We probably need to have a better definition here. Where is the right place to raise this point for discussion in Debian? Should I bring this up on the debian-embedded list? Are there other stakeholders who would have input regarding the array of available uclibc ABIs and how to specify these? Debian-embedded contains people who know about uclibc stuff. (ron, Bernard Link, virtuoso, Simon richter) Comments anyone? Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110217225436.gu22...@dream.aleph1.co.uk
Re: dpkg armhf patch acceptance status?
sorry, markos - and again, apologies to all, but i am actually now getting deeply concerned. allow me to ask you this, markos. why, if someone says, i have an idea that could help you, and could help the debian project in general, it's complex, it's been misunderstood frequently in the past (not necessarily by you, personally and specifically), but i'd like to re-iterate in the context of this discussion how that idea may help, would you then say your whole idea's s**t? :) to illustrate, with some questions, why i am concerned at the response received: * are you, markos, pleased to be the sole exclusive developer on the armhf project, such that you wish to retain complete control of it until such time as it is finished? * are you, markos, *wishing* to impose stress and pressure onto debian developers, specifically the dpkg team? * are you, markos, wishing to deliberately cause yourself harm by placing *yourself* under stress and pressure, by deliberately dismissing ideas that would, if implemented, allow you to reduce both the amount of stress and pressure, as well as the dependence on yourself, allow others to participate at leisure and so on? because, ridiculous as it may sound, those are the only possible reasonable _honest_ motives for you being so dismissive of what i wrote. reducto ad ab... can't even remember the damn word... absurdum, logically we conclude that there could be a hidden and unspoken motive, instead. if there is, SPEAK it. please get it out into the open so that we may resolve it, and thus not have these continued ridiculous misunderstandings which are plaguing interactions with genesi employees on public mailing lists. i find that people forget, before speaking: archives are forever. i point this out to them, retrospectively, and they go ballistic, blaming _me_, against all logic, for their own words. so - SPEAK, markos. correct me if i have misunderstood, and i will apologise for any misunderstandings. l. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktin_ars2fsvvcvuw6dg14jokug753sfpncxch...@mail.gmail.com
Re: dpkg armhf patch acceptance status?
Hi Luke, On Fri, Feb 18, 2011 at 12:06:27AM +, Luke Kenneth Casson Leighton wrote: sorry, markos - and again, apologies to all, but i am actually now getting deeply concerned. allow me to ask you this, markos. why, if someone says, i have an idea that could help you, and could help the debian project in general, it's complex, it's been misunderstood frequently in the past (not necessarily by you, personally and specifically), but i'd like to re-iterate in the context of this discussion how that idea may help, would you then say your whole idea's s**t? :) to illustrate, with some questions, why i am concerned at the response received: * are you, markos, pleased to be the sole exclusive developer on the armhf project, such that you wish to retain complete control of it until such time as it is finished? * are you, markos, *wishing* to impose stress and pressure onto debian developers, specifically the dpkg team? I think you are working from a buggy assumption here. The problem is not that infrastructure is lacking to let Konstantinos et al. get on with making an armhf port out of the Debian archive; the problem is that they are currently blocked on getting armhf *into* the Debian archive, because that requires agreement with the dpkg maintainers about how dpkg should behave to recognize this new architecture. You may be right that a bitbake-compatible git repository is the absolute slickest way to nearly effortlessly maintain a delta against a distribution. But it doesn't actually matter if you're right about this, because nearly effortless is not zero work, and it's *not* sustainable to carry a delta in the long term - which is why the (right) goal is to merge the armhf work into Debian so that there *isn't* a delta. Bitbake doesn't help with that goal; the only way to help that goal is to have the sometimes-difficult conversations with the Debian maintainers that let us arrive at a consensus about how these things should be put together. Which is what this thread is about. :) Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: dpkg armhf patch acceptance status?
On Fri, Feb 18, 2011 at 12:25 AM, Steve Langasek vor...@debian.org wrote:
Hi Luke,
allo steve.
I think you are working from a buggy assumption here.
i'm pleased - and relieved - to see the word think.
The problem is not
that infrastructure is lacking to let Konstantinos et al. get on with making
an armhf port out of the Debian archive; the problem is that they are
currently blocked on getting armhf *into* the Debian archive, because that
requires agreement with the dpkg maintainers about how dpkg should behave to
recognize this new architecture.
yes. i based my response on this problem.
You may be right that a bitbake-compatible git repository is the absolute
slickest way to nearly effortlessly maintain a delta against a distribution.
But it doesn't actually matter if you're right about this, because nearly
effortless is not zero work, and it's *not* sustainable to carry a delta
in the long term - which is why the (right) goal is to merge the armhf work
into Debian so that there *isn't* a delta.
precisely. this is another, (clearer or at least different) way of
stating what i've been advocating. by having such a delta-maintaining
tool, complex sets of deltas can be maintained indefinitely, or in
fact completely reworked.
the fact that the delta-maintaining tool is maintaining deltas
against debian packages, which are themselves deltas against upstream
packages, does create some rather interesting challenges but i'm sure
that debian people are up to that without their heads melting, eyes
bleeding and any more screams emanating than would normally occur on a
day-to-day basis.
... in fact, *binggg*, light-bulb moment... now that i think about
it, why isn't the debian archive system *itself* being used for this
task?? ermm... the principle exists in the form of the debian kernel
source packages, right?
so why not use buildd to have debian packages that contain patches
and a preinst script that does apt-get source {packagename} and then
applies the patches [that markos is currently maintaining by hand].
call each of them armhf-patch-botchjob-{packagename}, for now, for all
i care - it's not like they're going to get uploaded to ftp.debian.org
any time soon, but they *could* be dumped on
ftp.armhf-in-development.debian.org hmmm [why couldn't they be
uploaded to ftp.debian.org?? i can't think of a reason why not..
anyone that installed them would just end up cluttering up
/usr/local/src or wherever the packages dumped and ran the patches on
the preinst-triggered debian-package source code...]
that approach would do the same bloody job, pretty much!!
... does anyone else understand that paragraph? could someone make
an attempt, in a similar vein to what steve has done, starting with
so let me get this straight: let me reiterate that, please do correct
any assumptions made.
Bitbake doesn't help with that goal;
not without some code - estimated to be approximately... 600 lines -
comprising a hybrid of python, shell-script and bitbake recipes [and
bitbake classes, if you're familiar with the terminology] that, at
their heart, kiinda replicate the functionality of buildd. the first
version might actually be simpler than that, because the first
version would be to *not* try to tackle cross-compiling, but would be
tasks consisting of nothing more than calling dpkg-buildpackage -t
${DEBIAN_RULES_TARGET}. the heavy lifting - the vertical and
horizontal interdependencies - is what bitbake-the-tool is good at,
and is already coded and designed to do.
all the hybrid python+shell-scripts+recipes have to do is define the
horizontal dependencies (oh look, that's nothing more than reading
dpkg stuff, funny that, there's a python library for that); define the
vertical dependencies (oh look, those are pretty linear), and define
the links between the two [build done, install completed - next
rdepend can proceed with apt-get source task]
i outlined this approach a couple months back on ... huh. debian-arm? yeah.
it was _completely_ misunderstood, with, as i understand it, numerous
people privately believing that i was attempting to take over debian,
or that i was recommending that years and decades of work by some of
the most committed debian developers should be completely abandoned in
favour of using openembedded i mean it was _really_ weird some of the
stuff i was hearing.
i had a prolonged, intensive and quite amicable discussion with
markos, clarifying many of the misunderstandings, and thus allowing me
to subsequently make a much clearer and concise description, which was
good.
but... yeahh, someone tell me: does the use dpkg to manage deltas to
dpkg packages idea fly, as an alternative? it'd hardly need any
coding (which is nice) - might even be able to create a script which
writes the dpkg-delta-package based on a template.
the only way to help that goal is to
have the sometimes-difficult conversations with the Debian maintainers that
let us arrive at a
Re: dpkg armhf patch acceptance status?
On Wed, Sep 08, 2010, Guillem Jover wrote: Steve wondered why this is the case, and that's because for cross-compiling purposes dpkg-architecture infers the host architecture from the CC environment variable through the -dumpmachine option. Chaning this is possible but, would break a current way of cross-compiling which has been around for a long time. Should perhaps use dpkg --print-architecture instead? or is it for cross-compiling dpkg itself on systems without dpkg? -- Loïc Minier -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100913095452.gb21...@bee.dooz.org
Re: dpkg armhf patch acceptance status?
Steve Langasek vor...@debian.org writes: On Wed, Sep 08, 2010 at 11:40:13AM +0200, Guillem Jover wrote: This also causes issue with not being able to have installed two cross-toolchains for say armel and armhf as they share triplet, although you can use the armel toolchain with few options to build for armhf, but then you'd need to specify those as part of the CC variable. Also that also happens with biarch, you can produce i386 binaries from an x86_64 toolchain, yet they both have their own triplet. I'm just wondering if this is also the case for mips triarch, or do those have each their own triplet, and is only arm that has this issue? mips have distinct triplets for each of their archs, yes. Anyway, ideally I'd rather see this addressed by giving armhf a real triplet, which would also make multiarch life way easier as there'd not be any need to define an artificial set of neutral architecture names to be able to place objects in the file system. I realize this is ideal, but: - there's been very strong upstream pushback on this, asserting that this is the correct triplet to use for both arm calling conventions, so if we require a distinct triplet for armhf (instead of using the vendor field), that's going to block any armhf port for quite a while (possibly indefinitely) - armhf was not the sole motivation for the proposal to define neutral architecture names; x86 was already a problem because of the changing triplets depending on which level of instruction set compatibility is targeted. *Both* of these examples show that GNU triplets are not defined in a way that they map directly to what we need for multiarch, so it's best to explicitly define our mapping externally. So even if you persuaded the upstream toolchain folks to specify a new triplet for armhf after all, I think we should still go ahead with a separate name mapping table for multiarch. Cheers, Note that uclibc also suffers this problems. x86_64-linux-uclibc is in no way unique as different uclibc compile options create different ABIs all with the same tripplet. I filed a wishlist bug against dpkg-architecture to please provide DEB_HOST_ABI / DEB_BUILD_ABI and to start giving that as DEB_HOST_GNU_TYPE / DEB_BUILD_GNU_TYPE initialy. Ports where this is insufficient can then extend the table to give a unique value. MfG Goswin -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87tylyoxtv@frosties.localdomain
Re: dpkg armhf patch acceptance status?
Hi! [ I'm leaving for two days, and running out the door just right now, so this mail is a bit rushed, and might contain inaccuracies and repetition due to lack of proper review, sorry about that, I'll try to clarify anything unclear once I get back. ] On Tue, 2010-09-07 at 14:01:37 +0300, Konstantinos Margaritis wrote: I really would like to know the stance of the dpkg maintainers regarding the armhf dpkg patch. I have a ton of armhf patches that I'm waiting to file as bug reports, but without the dpkg patch, those patches would be useless, so I'm holding back, but that in the meantime increases the workload as newer packages appear all the time and I have to forward port the armhf patches all the time. Plus, the whole port is unusable without dpkg functioning properly. The patched version I have uploaded in debian-ports works fine without any side-effects whatsoeer. I'm not asking for immediate acceptance, but even a short mail of 'it's ok, but needs more work here and there' will do. I don't quite like the current implementation, which abuses the vendor for information related to the ABI. So, recapping a bit the long thread about the new port: I agree with Paul Brook that abusing the vendor in this way poses a compatibility issue with upstreams, I'd rather not use something like this which is probably Debian specific. We currently need something like this in dpkg-dev because the mappings need to be bidirectional, as dpkg-dev needs to be able to convert from GNU triplet to Debian architecture and the other way around. Steve wondered why this is the case, and that's because for cross-compiling purposes dpkg-architecture infers the host architecture from the CC environment variable through the -dumpmachine option. Chaning this is possible but, would break a current way of cross-compiling which has been around for a long time. The toolchain has the same triplet for binary incompatible producing objects, which seems like a bug/misfeature to me, and that's one of the assumptions dpkg-dev has relied on, in the same way as multiarch when deciding to use the triplet as a unique token for the installation directories. Although one can produce binary incompatible output with normal gcc options, like changing the calling conventions with something like for example -fpcc-struct-return, but those are not part of the default ABI, and are expected and warned as producing incompatible binaries. This also causes issue with not being able to have installed two cross-toolchains for say armel and armhf as they share triplet, although you can use the armel toolchain with few options to build for armhf, but then you'd need to specify those as part of the CC variable. Also that also happens with biarch, you can produce i386 binaries from an x86_64 toolchain, yet they both have their own triplet. I'm just wondering if this is also the case for mips triarch, or do those have each their own triplet, and is only arm that has this issue? Anyway, ideally I'd rather see this addressed by giving armhf a real triplet, which would also make multiarch life way easier as there'd not be any need to define an artificial set of neutral architecture names to be able to place objects in the file system. But if this is not going to happen, and thus the assumptions dpkg-dev is making have been just wrong, then I'd rather drop the bidirectional mappings, and be done with it. This will need careful consideration though, as it's breaking a current interface, but something that could be done for dpkg 1.16.x. I can propose a patch for this once I get back. thanks, guillem -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100908094013.ga28...@gaara.hadrons.org
Re: dpkg armhf patch acceptance status?
On Wed, Sep 08, 2010 at 11:40:13AM +0200, Guillem Jover wrote: This also causes issue with not being able to have installed two cross-toolchains for say armel and armhf as they share triplet, although you can use the armel toolchain with few options to build for armhf, but then you'd need to specify those as part of the CC variable. Also that also happens with biarch, you can produce i386 binaries from an x86_64 toolchain, yet they both have their own triplet. I'm just wondering if this is also the case for mips triarch, or do those have each their own triplet, and is only arm that has this issue? mips have distinct triplets for each of their archs, yes. Anyway, ideally I'd rather see this addressed by giving armhf a real triplet, which would also make multiarch life way easier as there'd not be any need to define an artificial set of neutral architecture names to be able to place objects in the file system. I realize this is ideal, but: - there's been very strong upstream pushback on this, asserting that this is the correct triplet to use for both arm calling conventions, so if we require a distinct triplet for armhf (instead of using the vendor field), that's going to block any armhf port for quite a while (possibly indefinitely) - armhf was not the sole motivation for the proposal to define neutral architecture names; x86 was already a problem because of the changing triplets depending on which level of instruction set compatibility is targeted. *Both* of these examples show that GNU triplets are not defined in a way that they map directly to what we need for multiarch, so it's best to explicitly define our mapping externally. So even if you persuaded the upstream toolchain folks to specify a new triplet for armhf after all, I think we should still go ahead with a separate name mapping table for multiarch. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
dpkg armhf patch acceptance status?
Hi all, I really would like to know the stance of the dpkg maintainers regarding the armhf dpkg patch. I have a ton of armhf patches that I'm waiting to file as bug reports, but without the dpkg patch, those patches would be useless, so I'm holding back, but that in the meantime increases the workload as newer packages appear all the time and I have to forward port the armhf patches all the time. Plus, the whole port is unusable without dpkg functioning properly. The patched version I have uploaded in debian-ports works fine without any side-effects whatsoeer. I'm not asking for immediate acceptance, but even a short mail of 'it's ok, but needs more work here and there' will do. I'm posting this with both hats on, Genesi and Debian (I recently rejoined Debian as a DD). WRT Genesi, the company has been a long time supporter of Debian -the recent donation of dozens of EfikaMX systems to DDs and 2x2TB SATA disks for storage of the debian-ports archive only strengthens that position. WRT Debian, I know that the port is not yet an accepted official one -heck, it's not even usable yet, but the patch -or something that provides the same functionality- is absolutely needed for the port to actually exist and evolve. I would really appreciate a reply. Regards Konstantinos Margaritis Genesi USA, Senior Software engineer, armhf port maintainer -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201009071401.38436.mar...@genesi-usa.com
