Re: Re-evaluating architecture inclusion in unstable/experimental
On 9/28/18 11:26 PM, Adam D. Barratt wrote: > On Fri, 2018-09-28 at 14:16 +0200, John Paul Adrian Glaubitz wrote: >> So, it's not always a purely technical decision whether a port >> remains a release architecture. It's also often highly political and >> somehow also influenced by commercial entities. > > Please don't make implications like that unless you can back them up. Well, I cannot prove it. But when I see that we have ports as release architectures with hardware where atomics in hardware don't even work correctly and the virtual address space is limited to 2 GiB per process while on the other hand perfectly healthy and maintained ports like powerpc and ppc64 which have actually a measurable userbase and interest in the community are axed or barred from being a release architecture, then I have my doubts that those decisions aren't also driven by commercial interests or politics. I have seen IBM people on multiple occasions in various upstream projects trying to remove code for older POWER targets because they insisted anything below POWER8 is not supported anymore. In some cases like Golang with success [1]. > Adam > (involved to greater or lesser extent in every decision as to whether > an architecture should be added to or removed from testing over the > past almost decade, with no commercial interest involved in any way) I understand that. But if stuff that gets removed despite people using it and despite others maintaining it, I am having my doubts. And it has happened more than once where I had to explain users why there aren't any stable releases anymore they can install on their PowerPC-based machines. I really do not mean to accuse anyone of malevolence, I am merely speaking from my personal observations that sometimes such decisions do not necessarily meet the expectations of our users and that there might be a path for improvement, e.g in the form of support tiers like they exist in NetBSD. Thanks, Adrian > [1] https://github.com/golang/go/issues/19074 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Re-evaluating architecture inclusion in unstable/experimental
On Fri, 2018-09-28 at 14:16 +0200, John Paul Adrian Glaubitz wrote: > So, it's not always a purely technical decision whether a port > remains a release architecture. It's also often highly political and > somehow also influenced by commercial entities. Please don't make implications like that unless you can back them up. Adam (involved to greater or lesser extent in every decision as to whether an architecture should be added to or removed from testing over the past almost decade, with no commercial interest involved in any way)
package rsyslog depends on liblognorm2 (mini.iso hardware install error)
Hello, I have been trying to install Debian/Hurd from a USB stick with the mini.iso file from: http://cdimage.debian.org/cdimage/ports/latest/hurd-i386/ However, during the "Install the base system" phase, when it hits somewhere around ~70% complete, I get the following warning: "Debootstrap warning Warning: Failure while configuring base packages. This will be re-attempted up to five times." Followed by a "Debootstrap warning Warning: See the log for details" warning message. These two messages repeat 5 times before it spits this error out: "Failed to install the base system The base system nstallation into /target/ failed. Check your /var/log/syslog or see virtual console 4 for the details." Anyway... The /var/log/syslog explains that the attempted installation of rsyslog is what halted the debootstrap phase, due to a missing dependancy (liblognorm2): "Errors were encountered while processing: rsyslog dpkg: dependency problems prevent configuration of rsyslog: rsyslog depends on liblognorm2 (>= 1.1.2): however: Package liblognorm2 is not installed." I would really appreciate some help with this. I'm very sorry for bothering you all. -- Regards, Muto (https://muto.ca)
Re: Re-evaluating architecture inclusion in unstable/experimental
Hello! I just saw this mail this morning by accident while browsing the archives, I am not subscribed to debian-devel. > The ftpmaster team would like to clarify which Debian ports should and/or would like to continue to be part of Debian unstable and experimental. I'm not sure what context you are referring to? Are you talking about architectures that are present in the main archive or do you also include Debian Ports which has its own FTP server and buildds maintained outside DSA? > As outlined on the Debian Archive Criteria page[0], the key points to consider are whether the architecture has been part of a stable release, whether it is *likely* to be part of a stable release, as well as whether it currently has a sensible number of active maintainers. All ports in Debian Ports have at least one maintainer otherwise it wouldn't be possible to keep the pace with unstable. Furthermore, several of the ports are in very healthy condition and even surpass some release architectures. The powerpc and ppc64 ports, for example, build more packages than any of the mips* ports. As for the kernel maintenance, except for Alpha, all the ports have at least one kernel maintainer: * hppa: actively maintained by two people who also maintain the toolchain * ia64: maintained by one paid developer at Intel * m68k: maintained by multiple independent kernel maintainers, at least five people involved upstream; port is also getting new drivers * powerpc/ppc64: maintained mostly by IBM people * sh4: maintained by two kernel maintainers * sparc64: used to be maintained by a team at Oracle but Oracle recently changed their mind about Linux on SPARC; now it's back to David Miller and some additional volunteers * x32: maintained by the people who maintain the x86 port of the kernel > Whilst you may be happy to continue the work of maintaining the port regardless, don't forget that excess or otherwise unnecessary architectures involve a shared maintenance burden as well as incurring non-trivial requirements on mirror/Debian resources. Debian Ports has its own mirrors. Besides, I think one of the main selling points of Debian is its portability. If we take away this feature, we become less attractive. If the maintenance burden is too high, it might be an idea to switch to a more flexible and powerful infrastructure like SUSE's OBS which makes handling of new ports much easier. It's very easy to set up your own OBS, so people within SUSE do that to maintain their own ports, for example. > The statistics and graphs available on the debian-ports page[1] may provide some objective statistics or reflection on the actual suitability of your architecture's continued inclusion. Jepp. And as you can see, several ports that are thought to be dead long time ago are healthier than some of the official Debian release architectures simply because there are huge communities behind it. The m68k port has a very strong and enthusiastic community which is why the port has already survived multiple other architectures in the kernel like TileGX and similar. There are people building new m68k hardware, writing new drivers and there is even an ongoing effort to create an m68k backend for LLVM so that we can eventually even start building Rust packages (I have already added partial target support for m68k in a local Rust branch). So, it's not always a purely technical decision whether a port remains a release architecture. It's also often highly political and somehow also influenced by commercial entities. Although I think Debian, being a community distribution, should be more oriented towards its community and not towards commercial interests. > So, in the first instance, would you like to continue being part of unstable/experimental? All Debian Ports architectures [1] should remain part of unstable and experimental and are very actively maintained by the Debian Ports team. You can find us in #debian-ports on OFTC. FWIW, we have our own instance of the transition tracker: > https://ben.jrtc27.com/ Thanks, Adrian > [1] https://buildd.debian.org/stats/graph-ports-big.png -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
GNU tar -Holdgnu w/o fakeroot seems to be break dpkg 1.19.1
Hi! I was checking the dpkg 1.19.1 FTBFS on the Hurd, and noticed few things: * GNU tar with -Holdgnu seems broken (?) when packing a fifo, as it stores at least the S_IROOT mode bit, which makes GNU tar encode the mode data in base-256 (dpkg suppports that just fine, but it's still unexpected, and seems incorrect to me). None of the other tar formats show this behavior. * None of the other dpkg tests fail except for this one. * dpkg is now being built w/o fakeroot due to the R³ field set to no. * Building the source with fakeroot again makes GNU tar with -Holdgnu not store said bit, so it's a possible workaround for a dpkg porter build, probably. So while I could workaround this in the test suite, I think it'd be better to investigate why GNU tar behaves this way, and possibly fix it there. Thanks, Guillem
