Re: Bug#1059870: aboot: Please help testing dropping a.out.h support
On Tue, 2 Jan 2024 at 21:00, John Paul Adrian Glaubitz wrote: > > On Tue, 2024-01-02 at 18:07 +, Dimitri John Ledkov wrote: > > For cross building, as far as I can tell one needs to build the tool > > twice - once for the BUILD architecture and once for HOST > > architecture, use one during the build and package the other one into > > the deb. > > That's correct and I am currently pondering over a clever way to do that. > > > > I will most likely just copy the relevant definitions out of aout.h, both > > > the generic and the alpha-specific stuff in order to both be able to drop > > > reliance on aout.h in the kernel as well as make the package fully cross- > > > buildable. > > > > But why? as far as I can tell, the a.out code path is never executed > > as it seems like Debian has been using ELF based vmlinuz since like > > before 2009. Are you sure that the a.out codepath of objstrip.c is > > needed or executed at all? > > > > Or am I missing something, and like objstrip.c portions are executed > > against some other a.out formatted things which are not Linux kernel? > > > > Should I provide a patch that adds printfs during a.out codepath > > block, to see if it actually is ever executed? > > I think it's still reasonable to keep a.out support in the tool because > users might use it for a.out binaries generated from other tools. Which tools? given that support has been dropped to execute any binaries like that everywhere. This still sounds very hypothetical, given that code path is specifically for vmlinux kernel only. > Besides, > it's just a matter of copying a few header definitions, so not really a > blocker unless I am missing something. > > > > > > > I would also prefer to get all relevant changes upstreamed. > > > > > > > Upstream has policy of not carrying dead code, which in this case its > > what it is for kernels built in like last decade. > > I was talking about aboot upstream which is maintained by Matt Turner from > Gentoo these days [1]. Ok, and I'm talking about linux kernel copy of aboot at https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/alpha/boot Can you please test the debdiff I have attached, such that I can confirm with linux kernel upstream that I can drop a.out.h support there? I do not have access to alpha, and currently this is the remaining piece holding up a.out.h in linux kernel upstream on x86 alpha m86k mips. Which would be nice to drop. > > Adrian > > > [1] https://github.com/mattst88/aboot/ > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer > `. `' Physicist > `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- Dimitri Sent from Ubuntu Pro https://ubuntu.com/pro
Re: Bug#1059870: aboot: Please help testing dropping a.out.h support
On Tue, 2 Jan 2024 at 17:48, John Paul Adrian Glaubitz wrote: > > Hi Dimitri! > > On Tue, 2024-01-02 at 17:37 +0000, Dimitri John Ledkov wrote: > > a.out support has been dropped in upstream kernel. However a.out.h > > header is still being using by abootimg tool via objstrip.c. It has > > support for both a.out image types and ELF. I have blidly dropped > > a.out.h support and made ELF support mandatory in > > https://lore.kernel.org/all/20231123180246.750674-2-dimitri.led...@canonical.com/ > > but I have no way to build it for alpha or test if everything still > > works. Upgrades, installed systems, and cd-boot. > > > > Could you please consider the attached NMU, build it and test it, and > > let me know if everything still works. Cause then a.out.h header can > > be removed from upstream linux kernel on all architectures. > > I have actually already looked into patching aboot myself to deal with the > aout.h issue since I want to make the bootloader fully cross-buildable [1]. > For cross building, as far as I can tell one needs to build the tool twice - once for the BUILD architecture and once for HOST architecture, use one during the build and package the other one into the deb. > I will most likely just copy the relevant definitions out of aout.h, both > the generic and the alpha-specific stuff in order to both be able to drop > reliance on aout.h in the kernel as well as make the package fully cross- > buildable. But why? as far as I can tell, the a.out code path is never executed as it seems like Debian has been using ELF based vmlinuz since like before 2009. Are you sure that the a.out codepath of objstrip.c is needed or executed at all? Or am I missing something, and like objstrip.c portions are executed against some other a.out formatted things which are not Linux kernel? Should I provide a patch that adds printfs during a.out codepath block, to see if it actually is ever executed? > > I would also prefer to get all relevant changes upstreamed. > Upstream has policy of not carrying dead code, which in this case its what it is for kernels built in like last decade. > Thanks, > Adrian > > > [1] https://github.com/mattst88/aboot/issues/5 > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer > `. `' Physicist > `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- Dimitri Sent from Ubuntu Pro https://ubuntu.com/pro
Please help testing dropping a.out support from aboot
Upstream linux kernel has deprecated a.out object format a while ago. However aboot tool still has support for it, which is keeping a.out.h header in the linux kernel. I'm trying to remove it, but to achieve this somebody needs to test that upgraded aboot still works. See details at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059870 And https://lore.kernel.org/all/20231123180246.750674-2-dimitri.led...@canonical.com/ I have ported objstrip.c to require ELF format kernel, and drop a.out format kernel, but I have no way to test this. -- Dimitri Sent from Ubuntu Pro https://ubuntu.com/pro
Re: [Stretch] Status for architecture qualification
On 14 June 2016 at 20:22, wrote: > On 2016-06-14 03:06, Philipp Kern wrote: >> >> On Mon, Jun 13, 2016 at 07:33:56PM +, Niels Thykier wrote: >>> >>> Philipp Kern: >>> > On 2016-06-05 12:01, Niels Thykier wrote: >>> >> * amd64, i386, armel, armhf, arm64, mips, mipsel, powerpc, ppc64el, >>> >>s390x >>> >>- *No* blockers at this time from RT, DSA nor security. >>> >>- s390, ppc64el and all arm ports have DSA concerns. >>> > What is the current DSA concern about s390x? >>> The concern listed as: "rely on sponsors for hardware (mild concern)" >>> >>> As I recall the argument went something along the lines of: >>> >>> "Debian cannot replace the hardware; if any of the machines dies, we >>> need a sponsor to replace it. If all of them dies and we cannot get >>> sponsored replacements, we cannot support the architecture any longer" >>> >>> (My wording) >> >> >> Yeah, but that's unfortunately one of the universal truths of this port. >> I mean in theory sometimes they turn up on eBay and people try to make >> them work[1]. >> >> It also seems true for other ports where we commonly relied on sponsors >> to hand us replacements. But maybe it's only ppc64el these days, maybe >> there are useful builds available for the others (including arm64 and >> mips) on the market now. >> >> Kind regards and thanks >> Philipp Kern >> >> [1] https://www.youtube.com/watch?v=45X4VP8CGtk >> (Here's What Happens When an 18 Year Old Buys a Mainframe) > > > Fun story, i had a client who was considering getting their hands on a Z9, > they asked me a few others to go with them to see IBM present a demo of it. > Long story short the IBM guys started a job and literally started pulling > CPU and Mem boards out of the machine mid job. The error log on the OS/2 > maintenance laptop was going crazy, but the OS kept running the job. > > In other words, i don't think a s390x box will ever just die. Really > interesting machines to say the least, hopefully one day i will get to play > with one. The other issues with s390x is that in most cases you don't buy > them. You essentially lease the CPU usage and IBM charges you based on how > much CPU usage you've consumed over a given time. It makes me wonder how > they ever get on eBay. IBM typically takes them back after you stop paying > for it. > In the talk he did say that for that acient machine he was offered subscription to the upgraded z/OS for some small amount of dollars a quarter. There is openmainframe project https://www.openmainframeproject.org/ , which I believe offers access to z/VM instances hosted by Marist colledge. At the openmainframeproject EU meetup, it was indicated that SUSE joined with indication that Open Build Service might be able to use resources hosted by Marist. I wonder if it makes sense to reach out, and see if there are resources available to use as porter boxes & build boxes. That way Debian might be able to get such donated resource available on ongoing basis and hopefully with some hw support. -- Regards, Dimitri.
gnutls28 transition
Hello all, gmp has been recently re-licensed and all architectures and ports have the updated gmp in jessie/sid. Well, all but powerpcspe & x32 both of which recently have negative slope on their build status graphs. Thus GPLv2 and LGPLv3 compatible software packages can link against gnutls28. Should we start transition to gnutls28 by default, for all packages that are compatible? Can powerpcspe & x32 porters try to get latest gmp built? -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANBHLUgp=ahti1vk2rkqqa__aszjvxg7budltey+ezjfeaz...@mail.gmail.com
