arch-test and armel on arm64
Hi! Could you guys please educate me what's the matter with SWP on armel these days? It seems that almost no programs use it anymore. Should I remove the check for SWP from arch-test, so it reports a machine+kernel as capable of running armel even if it neither supports nor emulates this instruction? I somehow can't reproduce the crashes even with jessie's armel. I remember reproducing such fails, including more subtle cases where instead of a clean SIGILL the intruction was silently ignored, resulting in code that appeared to work unless there's multithreaded lock contention. So where did the crashes go? I don't claim to understand this anymore... Thus, would it be a good idea to just ignore the SWP issue and let debootstrap proceed? [Not subscribed, please CC.] Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ Have you accepted Khorne as your lord and saviour? ⠈⠳⣄
Re: Arch qualification for buster: call for DSA, Security, toolchain concerns
[Oy vey, crosspost list from hell -- not sure how to trim...] On Tue, Dec 11, 2018 at 09:46:21PM +0100, Gregor Riepl wrote: > I do think this just reinforces the point that second-class architectures > should have better, more robust support from the Debian project. > For example, arch-specific packages most decidedly have a place in Debian > The build and package delivery infrastructure should offer the same features > for both first and second class archs, including installer image building for > all "tiers" (stable, testing, unstable). It seems to me that the important bit is the testing suite. As a (now lapsed) x32 porter, I tried to implement that on my own (goal being an unofficial, weakly security supported[1] Jessie for x32). And tracking testing on my own proved to be too hard. What directly defeated me were binNMUs: with every arch having its own NMU counter and hidden triggers, this is already a mess. Add NMUs due to private ported packages, and all hell breaks loose. The rest is easy in comparison: a porter team can decide whether to snapshot testing as unofficial stable; point releases are a matter of running a buildd job (and fixing failures), same for security. We'd be able to concentrate on actual arch-specific issues. > The main difference should (IMHO) be the amount of support you get: While a > first-class arch will get faster fixes and a more stable dependency tree, > other archs will be more "sloppy", for example by not blocking stable releases > with their own RC bugs etc. Yeah, a completely one-way relationship: no issue on second-class would block first-class. > If this can be fulfilled, I don't think being a second-class arch will be such > a big deal. Not sure how far Debian is from this goal, but I can understand > that many DDs and DMs would rather invest their time into projects they have a > stake in, rather than hardware they don't (or don't want to?) understand. Yes, x32 suffers from needing obscure and hard to get hardware. :) Meow! [1]. The vast majority of security issues are non arch dependent, so blindly tracking and building first-class security updates gets us nearly all the way, reducing the work to babysitting buildds and looking into FTBFSes or yet another whole-new-language-ecosystem getting allowed into stable. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Ivan was a worldly man: born in St. Petersburg, raised in ⢿⡄⠘⠷⠚⠋⠀ Petrograd, lived most of his life in Leningrad, then returned ⠈⠳⣄ to the city of his birth to die.
Re: Building armel on arm64
On Mon, Jul 30, 2018 at 11:18:16PM +0200, John Paul Adrian Glaubitz wrote: > > On Jul 30, 2018, at 10:42 PM, Adam Borowski wrote: > > > > Also, this machine does have neon so it's not even armhf baseline. And so > > many packages compile but don't test. Thus, regressions from building on > > arm64 need not just hardware but also manpowers to detect. > > But why should compiling ARMv7 on ARMv8 automatically change the baseline > when it’s actually a hardwired configure option in gcc? There's way too many packages that do compile-time detection. > By the same logic, lots of the packages we build on ARMv7 machines for > armel wouldn’t work on ARMv5. And many probably don't, but such gear is so weak that a good part of packages simply have no one running them. > Plus, we can build on the experience that openSUSE made with building > ARMv6/7 on ARMv8. Why are we ignoring that? How do you propose to do that other than sometimes digging through their packaging for a patch here and there? ᛗᛖᛟᚹ -- // If you believe in so-called "intellectual property", please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable And Non-Discriminatory prices.
Re: Building armel on arm64
On Tue, Jul 24, 2018 at 08:43:02PM +0200, Christoph Biedl wrote: > If this is a concern, how to solve it? Have some native non-DSA > armel/armhf boxes where volunteers rebuild the archive and hope test > suites will catch such issues? The problem is not doing the rebuilds, it's tuits to actually analyze and report bugs. There are multiple such efforts: reproducible builds use a diverse bunch of hardware, I run a single Odroid-U2: (arch:any) https://angband.pl/deb/rebuild.pl (arch:all) https://angband.pl/deb/rebuild-all.pl yet didn't have the tuits to go through them in several months. Also, this machine does have neon so it's not even armhf baseline. And so many packages compile but don't test. Thus, regressions from building on arm64 need not just hardware but also manpowers to detect. Meow. -- // If you believe in so-called "intellectual property", please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable And Non-Discriminatory prices.
Re: ODROID XU4 and UEFI - Re: Cautionary tale: how to kill an SDCard with one simple command
On Wed, Jul 25, 2018 at 08:15:03PM +, Mark Morgan Lloyd wrote: > Really depends what you mean by an "image backup". I do a lot of stuff using > "ye olde traditional" dd, either between devices or more often making an > image of the entire device (i.e. including partition table etc.) to a file > and manipulate it there (e.g. by deleting a directory tree /after/ the data > has been copied). > > However when using something like dd there's a major problem: you either > want the storage medium to be removed so you can copy the filesystems > offline, or you need to shut every possible piece of running software down > (including things like your SSH daemon) so that nothing's writing to the > disc when you're trying to copy it. Needless to say the same considerations > apply when using dd to do a sector-by-sector copy from one device to > another. man fsfreeze Some filesystems (at least btrfs) can also enumerate all writes since a certain point of time, which allows backing up the full filesystem even without freezing writes, with incremental versions done very cheaply. > There are still ways of working round that sort of problem. For example, you > can copy an entire device using dd to capture boot segments and partition > layout, inspect and recreate the filesystems using mkfs, then use > [something] to copy files one at a time into the new filesystems taking care > that some bootloaders need a wakeup call when a file moves. Usually dd-ing the partition table and u-bootage, then rsync on filesystem data works pretty well. Unlike btrfs ways, rsync is not atomic, but most people consider it good enough. Meow! -- // If you believe in so-called "intellectual property", please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable And Non-Discriminatory prices.
Re: Using Alpine on Gmail
On Fri, Jul 13, 2018 at 11:16:18AM -0400, Alan Corey wrote: > Enough of that GUI nonsense, in 3 days Thunderbird couldn't index my gmail ^ > inbox, or download all the headers, or whatever it was doing. Here's your problem. Problems with gmail are not limited to shitting on your and everyone's you correspond with privacy (incl. giving your mails to third parties). It also drops random mails without any notification -- and, as you just noticed, fails badly with actual clients. That some clients are more amenable to breakage doesn't make gmail any more acceptable. Meow! -- // If you believe in so-called "intellectual property", please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable And Non-Discriminatory prices.
Re: pinebook session at debconf 2018?
On Sat, Apr 07, 2018 at 11:43:45AM +0800, gustavo panizzo wrote: > > is anyone else interested in having a pinebook session during debconf? I almost surely won't be on Debconf, but a bunch of relevant people will. It would be especially beneficial for you to concoct a plan to drag in Icenowy Zheng, in chains if must be -- most of Pinebook-specific code is hers (at least older parts; these days anarsoul is more active, icenowy having moved mostly to H6 stuff). She's geographically close, although there's the issue of needing not one but two visas (exit from one country named "China", entrance for the other "China"). A good bait can be mentioning that wens (Chen-Yu Tsai) is a local thus has no excuse wrt attending Debconf (and he already said he'll be there). > I don't know the current status of the pinebook with debian bits, i > purchased the serial cable a few days ago and I plan to play with it > (dunno if i'll have enough time to make it work before debconf) As in, headphone-UART-USB? It's a vital bit, without it any u-boot hackery other than writing a pre-made image is not really possible. You need to enable it first (in software in early models like mine, IIRC requires opening the laptop and flipping a switch in later models), thus it's much easier to test the cable from an already booted system. > I plan to port u-boot and kernel (as far as possible) from > https://github.com/anarsoul/linux-build/releases which works fine in my > pinebook, and its much newer than the BSP Upstreaming kernel patches seems to be stalled with no visible action at all for a long while. On the other hand, there's a recent flurry of drm/lima commits, it's possible this was the blocker (I didn't ask). If required parts are not in mainline close to Buster freeze, we can molest Ben Hutchings about applying this patchset in Debian; no point in doing that now as if everything goes well, patching then unpatching would be a waste of time. As for u-boot, there's only a few patches needed, I did not look, though. You also need the ATF; atf-allwinner in unstable already has all of Pinebook patches. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢰⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ ... what's the frequency of that 5V DC? ⠈⠳⣄
Re: Migrate a SD card from olinuxino lime to lime2 ?
On Wed, Jan 03, 2018 at 08:00:44PM +0100, Dominique Dumont wrote: > I'm going to upgrade my trusty olinuxino A20 lime to a lime2 board. Both > board > have to NAND or MMC memory and the kernel is installed on a SD card. > > To avoid a re-install from scratch, I'd like to re-use Sd card of the lime > board in the new lime2 board. > > Is is possible to use flash-kernel on the old board to setup the SD card for > the new board ? Yes, but I believe it's more convenient to do so from your big noisy box. apt install qemu-user-static cp -p /usr/bin/qemu-arm-static /mnt/.../usr/bin/ chroot /mnt/.../ This way you avoid editing the tree branch you're sitting on -- if anything goes wrong, you can't boot the sd card on either the old or the new board to fix the problem (unless you run entirely from eMMC). In theory, you can put an USB sd reader into the old board, but it's not much different from just doing this from the big box. > I was thinking of: > - running the following command on the old lime card: > FK_MACHINE="Olimex A20-OLinuXino-LIME2" flash-kernel > - move the SD card in the lime2 board > - boot the lime2 board and voilà... Should work, yeah. I'd recommend making a copy of the card, though -- this way you'll have _two_ functioning boards. And, saving an image of the card on a nearby piece of spinning rust -- preferably both before and after the operation, is also a good idea. Meow! -- // If you believe in so-called "intellectual property", please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable And Non-Discriminatory prices.
Re: Re: Re: debian and wol on Buffalo Linkstation WXL
On Thu, Dec 28, 2017 at 07:31:03AM +0800, Paul Wise wrote: > On Thu, Dec 28, 2017 at 3:25 AM, rosanna wrote: > > > ... but, at reboot, ssh and telnet access are no more available > ... > > any idea on what can be the cause? > > It is possible that Debian is not compatible with the version of the > Linux kernel available in the original rootfs, it might be too old for > either systemd or glibc. glibc in stretch requires kernel 3.2, systemd kernel 3.13. Most kernels you get on vendor images are 3.4, 3.8 or 3.10 -- all of them good for stretch in general but not for systemd; other packages with kernel requirements are extremely rare and unlikely to be involved. > You could try installing an older version of Debian or it is possible > that the community of Buffalo users has ported Buffalo's Linux patches > to a newer version of Linux. I'd first try without systemd; even kernel version aside, other init/rc combinations are more likely to work even when a required kernel option is missing or some other minor error happens. If you do require systemd for some reason, you'd need to go back to jessie; the pdf with instructions says jessie works with WXL. Jessie is also needed in case the vendor kernel is 3.0 (jessie's glibc needs 2.6.32, no idea about systemd). Meow! -- // If you believe in so-called "intellectual property", please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable And Non-Discriminatory prices.
Re: Porter roll call for Debian Stretch
On Fri, Sep 30, 2016 at 11:01:55PM +0200, Mathieu Malaterre wrote: > On Fri, Sep 30, 2016 at 10:34 PM, John Paul Adrian Glaubitz > wrote: > [...] > > On the other hand, some packages dropped support for PowerPC32 like Mono > > but this isn't a concern for most users, I would say. > [...] > > However I need to mention that the specific ppc/mono issue is in fact > pretty interesting. The long thread is on debian-powerpc@l.d.o but the > short version is that this issue only happen because we build the > ppc32 mono version on a ppc64 kernel, I know that since I did debug > this issue. Which, if I read the bug correctly, is a yet another case of a bogus build system looking at characteristics of the machine it's compiled on rather than baseline of the arch. And, per your own work, it's +patch +fixed-upstream. > I have not heard from the ppc64el porters, but I suspect ppc64 will > not be a release arch. So you need to take into consideration that for > powerpc to remain a release arch, one need minimal working ppc64 port. > Could we solve the situation of ppc64 for Stretch, could it be moved > to official release arch ? What would you need ppc64 for? Unlike i386, powerpc includes 64-bit kernels so users don't need multiarch: powerpc has: linux-image-4.7.0-1-powerpc - Linux 4.7 for uniprocessor 32-bit PowerPC (signed) linux-image-4.7.0-1-powerpc-smp - Linux 4.7 for multiprocessor 32-bit PowerPC (signed) linux-image-4.7.0-1-powerpc64 - Linux 4.7 for 64-bit PowerPC (signed) i386 has: linux-image-4.7.0-1-686-pae-unsigned - Linux 4.7 for modern PCs linux-image-4.7.0-1-686-unsigned - Linux 4.7 for older PCs linux-image-4.7.0-1-grsec-686-pae - Linux 4.7 for modern PCs, Grsecurity protection linux-image-4.7.0-1-686 - Linux 4.7 for older PCs (signed) linux-image-4.7.0-1-686-pae - Linux 4.7 for modern PCs (signed) Note the joke: "for modern PCs". Unless you do embedded it takes some serious dumpster diving to find a machine not better served by an -amd64 kernel (and thus multiarch). The i386 architecture is not self-contained, powerpc is. Thus, there is no need for ppc64 (userland), as long as powerpc has the toolchain to build 64-bit kernels. And that's a primary target for gcc upstream. -- A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month. Filter out and throw away the fruits (can dump them into a cake, etc), let the drink age at least 3-6 months.
Re: Porter roll call for Debian Stretch
On Fri, Sep 30, 2016 at 10:03:47AM +0200, Mathieu Malaterre wrote: > [Let's assume that we can't find a powerpc porter in time for Stretch.] Two potential porters stepped up, who might or might not be accepted. > 1. Will `powperpc` automatically be downgraded to simple port ? Or is > this also not automated and the port may simply be removed (eg. sparc) > ? Removal from the main archive isn't automatic, and assuming no serious kernel or toolchain breakage, I guess there's no reason for such removal to be hasty. On the other hand, place in -ports (aka second-class architectures) isn't automatic either, and relies on someone doing the work. > 2. Apart from loosing the automatic debian-installer stuff, what else > are we going to loose in that scenario ? Security support and stable release. -- A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month. Filter out and throw away the fruits (can dump them into a cake, etc), let the drink age at least 3-6 months.
