Re: [dd-list] Please use Architecture: linux-any
On Sat, Aug 20, 2011 at 01:11:40AM +0200, Samuel Thibault wrote: > Hello, > > Just a heads-up about Architecture: linux-any. The dd-list below is > a (non-exhaustive!) list of packages that kfreebsd/hurd maintainers > believe are candidates for using it in their debian/control file, > because they are probably not to be ported to non-Linux systems, due to > strong Linux dependency. > Daniel Baumann >btrfs-tools Can be used via fuse. There is no direct module, but you can get read only support via grub-mount, or rw via some uml thingy whose name eludes me and my 120-second google-fu. -- 1KB // Yo momma uses IPv4! signature.asc Description: Digital signature
Re: migration to testing
On Tue, Apr 06, 2010 at 01:05:52AM +0400, Stanislav Maslovski wrote: > As the original poster of that question on debian-mentors, I would > like to ask anyone who has access to a Debian/kFreeBSD installation to > test if fuse-convmvfs from sid works there (provided that fuse4bsd is > installed). My package builds on that architecture just fine, but > unfortunately I cannot test myself if it works there. Just install it yourself in virtualbox (slow, always works) or kvm (requires hardware support). I just lost several hours today trying, so here's a list of pitfalls: * You need to change the virtual network card. VirtualBox's default, "PCnet-FAST III (Am79C973)", is recognized by kfreebsd but doesn't see the network. "PCnet-PCI II (Am79C970A)" works fine. * You need a particular d-i build: http://d-i.debian.org/daily-images/kfreebsd-i386/20100221-11:20/monolithic/ (I assume -amd64 works too). Current d-i dailies are broken (the partitioner fails, even with a pre-partitioned disk, not letting you assign mount points). Don't use the sysinstall images either (they install but filesystem operations randomly fail). Rumours that d-i builds 20100306 or 20100223 are ok are untrue as well (won't even boot past the splash screen). -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100405230539.ga32...@angband.pl
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.
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: Debian Buster release to partially drop non-systemd support
On Mon, Oct 15, 2018 at 04:18:57PM +0200, Thorsten Glaser wrote: > Matthew Vernon wrote: > > >I'm aware of some work ongoing at the moment to try and improve matters > >(currently looking at elongind, for example). If anyone's got some > > What’s elongind? elogind? Never heard of it… elogind is an isolated part extracted from systemd-logind, maintained by Void people, and in use by several other distributions (Gentoo, Devuan, etc). It is a drop-in replacement for interfaces exposed by libpam-systemd. I'm using it for several months myself, and intended to package it in Debian, but had a lack of tuits to do so. I just started a new job and I think I'll have a small but non-zero amount of tuits in the evenings, but havent't finished moving and can't comfortably run anything that needs reasonable VMs (got nothing but a Pinebook with me), so I can't be of much help -- but if anyone wants to start the work on elogind, I'll try to do what I can. > >interest/effort in getting sysvinit (and related bits) in a better state > >for buster, do drop me a line. > > I’ve volunteered to help out earlier in the thread, within constraints > (but rather that than to see things go and break). The main problem with sysvinit is the lack of a git repository. There's a massive amount of opportunities for drive-by contributions, but no way to collaborate doing so. Then, there are nice-looking new upstream releases of sysvinit (three in this year, after several years of dormancy), but that'd require some real testing. Unlike elogind, it could perhaps reasonably be tested remotely... Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢰⠒⠀⣿⡁ 10 people enter a bar: 1 who understands binary, ⢿⡄⠘⠷⠚⠋⠀ 1 who doesn't, D who prefer to write it as hex, ⠈⠳⣄ and 1 who narrowly avoided an off-by-one error.
Re: Debian Buster release to partially drop non-systemd support
On Tue, Oct 16, 2018 at 07:47:36PM +0800, Benda Xu wrote: > Thorsten Glaser writes: > > … this applies to the shim only. I was a bit surprised seeing on > > someone else’s system that it was no longer installable, but almost > > all systemd-free systems of people I know do not use the shim anyway, > > so I’d take the Subject line with a few grains of salt. > > > > With only two modified binary packages (policykit-1 and udisks2) I’ve > > got a complete KDE environment running, except for network-manager, > > without the shim. People who do not use the full desktop environments > > (but the leaner ones, or just a window manager, or no X11 at all) have > > no problems with the current situation. 1. You need to recompile these packages, this is not something an average user or even sysadmin knows how to do. 2. You lose basic functionality like being able to shutdown from a GUI. > I was about to reply to this thread, but you have completely expressed > what I want to say: > > 1. systemd-shim is not necessary, even for DEs (except GNOME3). Alas, dependency chains say otherwise. What almost all of those packages want is logind functionality, but I quite don't get "why?". The only answer I received so far is "multiseat". Except, logind doesn't allow multiple GUI logins on the same machine for the same user no matter how many seats you connect from (this worked correctly before!), and it offers additional features for non-GUI logins either. So all this functionality does is telling you that user X is logged on via vt/pty Y. I recall a command named "who" on stone age Unices, and wonder what the whole hassle is about... But, it's not entirely unreasonable to provide the dbus interface logind users want. I'd prefer such an interface be a shim to standard Unix (like who -- utmp), which would have the added benefit of working on BSD and Hurd (which I don't personally care about but some do) -- yet such an daemon would have to be written. I for one don't volunteer to write it by tomorrow... Thus, let's use elogind which actually exists. Other pieces are some power management that has been moved into logind, etc. > 2. sysvinit-core is very stable and do not need new uploads. Exactly! Almost any changes in recent years were entirely because "systemd wants X". Thus, no wonders people are angry because of unnecessary work. Meow. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢰⠒⠀⣿⡁ 10 people enter a bar: 1 who understands binary, ⢿⡄⠘⠷⠚⠋⠀ 1 who doesn't, D who prefer to write it as hex, ⠈⠳⣄ and 1 who narrowly avoided an off-by-one error.
Re: Debian Buster release to partially drop non-systemd support
On Tue, Oct 16, 2018 at 05:54:34PM +0200, Petter Reinholdtsen wrote: > > SysV init leaves all the really hard problems to these, as it cannot > > really do much by itself. That's a fact that people that keep yelling > > "but SysV init was so easy!" keep finessing.. > > Absolutely. And the sysvinit boot system have lots of unsolved problems > we never got around to figuring out, related to disk and other device > setup. The main cause is the fact that the linux kernel is no longer > predicatble and sequencial, but asynchonous. No amount of wishful > thinking is going to bring is back to a world where static sequencing of > boot events is going to handle all the interdependencies. Systemd fails to solve them as well -- while introducing a lot of unsolved problems on its own, such as degraded RAID problems (no, it's not possible do to that in an event-driven way, you need a static sequence in at least some cases). But one thing we can agree on: the situation both approaches try to deal with is a mess. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢰⠒⠀⣿⡁ 10 people enter a bar: 1 who understands binary, ⢿⡄⠘⠷⠚⠋⠀ 1 who doesn't, D who prefer to write it as hex, ⠈⠳⣄ and 1 who narrowly avoided an off-by-one error.
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.
