- Package:
- bugs.debian.org
- Source:
- bugs.debian.org
- Submitter:
- Ivo De Decker
- Date:
- 2021-07-24 10:51:03 UTC
- Severity:
- wishlist
package: bugs.debian.org severity: wishlist Hi, During a discussion about architecture qualification, the release team concluded that it would be interesting to have a better way to track architecture-specific bugs. It would be nice to have BTS tags for each architecture that is currently in the archive. It might also make sense to have tags for the architectures on debian-ports, to be able to filter issues about these easily. Cheers, Ivo
This sounds reasonable; are only tags required, or do we need more infrastructure than that? These are the list of ports that I see: amd64 armel armhf hurd-i386 i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390x sparc avr32 sh What else am I missing? [I note that http://www.debian.org/ports/#portlist-released seems to have a reasonable list of ports, and http://anonscm.debian.org/viewvc/webwml/webwml/english/releases/sid/archive.data?view=markup has another; I'd like to reference a canonical location for ports (perhaps maintained by debian-ports or similar) so I don't have to figure out for myself which ports need a tag and what that tag should be, and which ports are just duplicates of other ports, and therefore don't need a tag.
There are 484 reports usertagged "debian-arm@lists.debian.org arm64". Please consider including "arm64" tag. Regards, Dmitrijs.
Don Armstrong dixit: Question is, where do you see them? This one got removed even from debian-ports for several reasons. I think there's sh4 but not just sh. Looking at the buildd pages is probably the best idea. Combining https://buildd.debian.org/status/package.php?p=mksh and http://buildd.debian-ports.org/status/package.php?p=mksh (and ignoring s390 removal) gives us this list: alpha amd64 arm64 armel armhf hppa hurd-i386 i386 ia64 kfreebsd-amd64 kfreebsd-i386 m68k mips mipsel powerpc powerpcspe ppc64 s390x sh4 sparc sparc64 x32 This keeps hppa, which I’ve seen have some activity recently. Even the list on debian-ports is out of date wrt. debian-ports architectures – it misses x32 and arm64, for example. Sorry about that. There seems to be nobody keeping this list up to date so looking at the buildds seems best. Another option is of course to look at what dpkg supports, unearthing things like armeb, arm, avr32, sh3, etc. bye, //mirabilos
Please add "hppa" Helge
Assuming that you are one of the hppa guys, how is the port doing? Any chance that the buildds will be up and running again anytime soon? Cheers, Adrian
Yes, think so. I'm working on that just right now... Helge
Very cool! Hope you guys will soon be where we already are with the m68k port :). Crossing my fingers! It's been sad to see the number of up-to-date packages in hppa dropping over the time. Keep us updated! Adrian
It should be going up now. Dave -- John David Anglin dave.anglin@bell.net
So, the buildds are already up and running? Shouldn't they be showing up on buildd.debian-ports.org [1]? Adrian http://buildd.debian-ports.org/status/architecture.php?a=hppa&suite=sid
I would strongly suggest not hardcoding this list and instead harvesting the Architecture fields of the Release files for oldstable -> experimental on ftp.d.o, ftp.d-p.o and maybe archive.d.o. We have made this mistake and similar ones (usually hardcoding release codenames) in the QA infrastructure and it has bitten us hard in the past. Lets not make that mistake here. The release files are the closest to a canonical list of ports. There are other ports out there not maintained on d-p.o (like the Interix or Solaris ones for example) but I don't think we need to bother about those until they move closer to Debian.
John Paul Adrian Glaubitz dixit: I think I saw buildd uploads for hppa on incoming.d.o this week. Paul Wise dixit: Huh, the Interix port is not vaporware? Interesting… bye, //mirabilos
Indeed: Very cool! Adrian
The list will be hardcoded, because it has to live in the Debbugs configuration file, and tags shouldn't disappear just because debian-ports or debian has dropped an architecture. That said, I was planning on setting it up so that I at least was notified when the set from cannonical location changed. OK.
The hardcoding is what I'd explicitly like to avoid. I would guess that it would be OK for the list to live in an external file and have the config file or the code load that file. The external file could then be generated daily/monthly using a command like this (or a perl equivalent). echo $(cat architectures) $(sed -n 's/Architectures: \(.*\)/\1/p' /srv/mirrors/debian*/dists/*/Release) | tr \ \\n | sort -u | sponge architectures
[Sorry, meant to cc. this to the list] I'm currently working with Helge Deller and John David Anglin on kernel testing with one of my machines (64 Bit SMP - HP Visualize J6750 workstation). I'm not one of the official developers, but willing to donate time and machine resources to keep the port going. We've had some pretty interesting breakthroughs recently, regarding the 64 bit SMP kernel. Dave L.
Most of the bugs affecting one of these also affect the other. I think it makes sense to add a single tag to cover both.
FWIW, I think dpkg resolved this quite nicely by splitting the architecture in two: $ head -n 99999 ostable cputable | grep -v "^#" ==> ostable <== uclibceabi-linux linux-uclibceabi linux[^-]*-uclibceabi uclibc-linux linux-uclibc linux[^-]*-uclibc gnueabihf-linux linux-gnueabihf linux[^-]*-gnueabihf gnueabi-linux linux-gnueabi linux[^-]*-gnueabi gnuspe-linux linux-gnuspe linux[^-]*-gnuspe gnux32-linux linux-gnux32 linux[^-]*-gnux32 gnulp-linux linux-gnulp linux[^-]*-gnulp gnu-linux linux-gnu linux[^-]*(-gnu.*)? gnu-kfreebsd kfreebsd-gnu kfreebsd[^-]*(-gnu.*)? gnu-knetbsd knetbsd-gnu knetbsd[^-]*(-gnu.*)? gnu-kopensolaris kopensolaris-gnu kopensolaris[^-]*(-gnu.*)? gnu-hurd gnu gnu[^-]* bsd-darwin darwin darwin[^-]* bsd-freebsd freebsd freebsd[^-]* bsd-netbsd netbsd netbsd[^-]* bsd-openbsd openbsd openbsd[^-]* sysv-solaris solaris solaris[^-]* uclibceabi-uclinux uclinux-uclibceabi uclinux[^-]*-uclibceabi uclibc-uclinux uclinux-uclibc uclinux[^-]*(-uclibc.*)? tos-mint mint mint[^-]* ==> cputable <== i386 i486 (i[3456]86|pentium) 32 little ia64 ia64 ia64 64 little alpha alpha alpha.* 64 little amd64 x86_64 x86_64 64 little armeb armeb arm.*b 32 big arm arm arm.* 32 little arm64 aarch64 aarch64 64 little avr32 avr32 avr32 32 big hppa hppa hppa.* 32 big m32r m32r m32r 32 big m68k m68k m68k 32 big mips mips mips(eb)? 32 big mipsel mipsel mipsel 32 little powerpc powerpc (powerpc|ppc) 32 big ppc64 powerpc64 (powerpc|ppc)64 64 big s390 s390 s390 32 big s390x s390x s390x 64 big sh3 sh3 sh3 32 little sh3eb sh3eb sh3eb 32 big sh4 sh4 sh4 32 little sh4eb sh4eb sh4eb 32 big sparc sparc sparc 32 big sparc64 sparc64 sparc64 64 big
Hey, As you know I've been looking for some stuff for a long time, and I think I've found it at last, just take a look http://nicola.sportlaw.us/4647 Sent from my iPhone, Debian FTP Masters
Dear Customer, USPS courier was unable to contact you for your parcel delivery. You can download the shipment label attached! Thank you for your time, Walter Nicholson, USPS Chief Office Manager.
Greetings, My name is Kayla Manthey, please reply me back?