Ubuntu initramfs (Was: Re: any reason for CONFIG_FUSE_FS=y)
On 8/9/22 11:38, Dimitri John Ledkov wrote: The fast majority of Ubuntu installations boot without initramfs at all. What makes you say this? Every Ubuntu system I've ever installed has an initrd.img-KERNEL_VERSION in /boot. In this context, I'm talking about systems installed using the stock installers (primarily server, but desktop was that way last I installed one using the stock installer). -- Richard OpenPGP_signature Description: OpenPGP digital signature -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Third party patch licensing
On 5/25/22 12:59, Athos Ribeiro wrote: I contacted the patch author to wonder how we could re-distribute the patch (see the discussion in [2]). They agreed to license it with the upstream project's license (AGPLv3), and I suggested the approach described in [4]. Since IANAL, I decided to ask devel-discuss if there's a better approach for licensing this patch or if this should be enough to include it as a delta. Note that this was submitted to Debian in [5], where I did raise this same concern. To be honest, I think general FOSS practice is to assume the patch is licensed the same as the code it is changing. In the case of copyleft licenses like (A)GPL, that's essentially* legally required (i.e. if someone is distributing modified versions*, they have* to be licensed under the same license). * One can quibble over whether the patch is distributing enough of the original code to be a derivative work. On the other hand, one can also quibble over whether a given patch is creative enough to even be copyrightable. If you really want to be safe (which it seems you do), all you need is for the author to confirm it's licensed as "AGPLv3 or later" or "the same as the project" or something unambigous. Putting the full license grant is one (and the most clear) way to do that, but it's not the only way to do it. -- Richard -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Include `::1 localhost` in /etc/hosts
On 4/20/22 15:48, Treysis wrote: Not having localhost to resolve to ::1 is getting problematic. Why? Can you elaborate on the issue(s) you're seeing? I've always assumed the trade-off is as follows: A) localhost resolves to ::1 (with or without 127.0.0.1 too) Pro: Things can use IPv6 instead of IPv4 locally. Pro: It becomes easier to have IPv6-only systems. Con: If a daemon doesn't listen on ::1, but does on 127.0.0.1, this change potentially breaks it. If the client(s) use IPv4 only, then as long as localhost points to both, it won't break. But if the client prefers IPv6, then it will break. If the client uses Happy Eyeballs, it will work, probably with slightly increased initial latency. B) localhost resolves to only 127.0.0.1 Pro: Daemons that listen only on 127.0.0.1 (because they're old) or only do so by default (because their default config is old or the user's config is old) still work. Con: IPv6 doesn't get exercised as much. Con: It's harder to have an IPv6-only system. All that said, at work, my systems have an /etc/hosts that is templated from Ansible, and my template for Debian and Ubuntu is based on Debian which points localhost to both 127.0.0.1 and ::1. I've not had any problems with that. It's way too late to change this for 22.04, but changing it for 22.10 might be ideal. That would give the maximal time to shake out bugs before the next LTS. -- Richard -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Installers, feature request
These days, just use TRIM support. As long as your filesystem isn't 100% full, this is going to achieve the same (actually better) effect. With either approach, the drive will have plenty of unused space for wear leveling. With TRIM, the drive also knows not to bother copying data around for sections of the disk that are not used. If, in spite of the advice above, you insist on doing the underprovisioning thing, look into setting an HPA (host protected area). You can tell the drive to report that it is smaller (e.g. you can ask your 200 GB SSD to report as 150 GB). An HPA, being a thing set on the drive, persists across installs. Keep in mind that setting an HPA erases all the data! -- Richard -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: ufw: add ability to restore ipset to support sshguard
Here's a bug report for it, which you may want to subscribe to: https://bugs.launchpad.net/ufw/+bug/1571579 FWIW, I too would love to see ufw have ipset support. I would use this for fail2ban integration as well as some permit rules for various applications. -- Richard -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Update Ubuntu Coturn Packages to 4.5.1.3
On 12/9/20 11:34 AM, Andrea Xheli wrote: Can Ubuntu please update the Coturn package currently on the Ubuntu 20.04 LTS https://packages.ubuntu.com/focal/coturn its 4.5.1.1 and the latest version is from https://github.com/coturn/coturn 4.5.1.3 Ubuntu does not update packages in a given version (e.g. 20.04), except for: * security issues: https://wiki.ubuntu.com/SecurityTeam/FAQ * high-impact bugs, safe bug fixes for applications, etc. through the Stable Release Updates (SRU) process: https://wiki.ubuntu.com/StableReleaseUpdates * kernel, Xorg, etc. via the Hardware Enablement (HWE) process: https://wiki.ubuntu.com/Kernel/RollingLTSEnablementStack Unless you're asking because of a security issue, the second one (SRU) is what you're looking for. You'd have to identify specific issue(s), file bug(s) with clear patches, and get someone to sponsor the upload. Also note that the coturn package is in Universe, which means it is community supported. You will most likely have to do all the fix work yourself (i.e. prepare the patched version and upload a .debdiff). So generally, in a situation like this, I'd backport the fix(es) myself, upload them to a PPA, and then decide how much I care about spending the work to get that pushed into Ubuntu itself. -- Richard -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: UBUNTU ARM64 DEB PACKAGES on DEBIAN RELATED VERSION
On 3/22/20 4:49 PM, Onur GURSOY wrote: > In general, you are doing something for ubuntu for packaging ? > I can say, Most of ubuntu packages are fully compatible with debian > buster/sid or something like that version? In practice, there is a fair amount of binary compatibility between Ubuntu and Debian. However, you really shouldn't use binary packages from one on the other. If you want Ubuntu packages, use Ubuntu; if you want Debian packages, use Debian. If you need a single package from the other, you should download the _source_ package (one place to find that is via https://packages.debian.org or https://packages.ubuntu.com) and rebuild that source package on your distribution. This would typically involve something like this: 1) tar zxf mypackage_1.2.3.orig.tar.gz 2) cd mypackage-1.2.3 3) tar --lzma -xf ../mypackage_1.2.3.debian.tar.xz 4) Optionally, edit debian/changelog (use the dch utility) 5) debuild -uc -us 6) If/when that fails, install the required dependencies and retry the build. "apt build-dep mypackage" can help if "mypackage" is already packaged in your distro. If the dependencies have changed, you may still need to install a few more packages separately. Where you'll run into trouble is if the package you're trying to build has newer dependencies than are available in your distro version. That has to be handled on a case-by-case basis. You may be able to weaken the dependency, or undo whatever change raised it, or you may have to backport the dependency. That last option can quickly turn into a mess if the dependency requires more upgraded dependencies; if you find that happening, just stop and upgrade your distro version instead. Good luck! -- Richard -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: State of libeigen3-dev in Ubuntu Focal
On 2/25/20 2:29 PM, Mike Purvis wrote: > Would it be reasonable to patch this change onto the current 3.3.7 > version to avoid dependent packages turning off warnings or doing other > workarounds? Without knowing the specifics of the patch, most likely. But you're running out of time. At this point, it's too late to get something into Debian testing and have it migrate to Focal. (I think Focal is syncing from Debian testing. If it's syncing from Debian unstable, then you have like 24 hours.) So it'd need to be a patch that goes direct into Ubuntu. The best thing to do would be to prepare a patch for the package, submit a bug report on Launchpad, attach a debdiff, and see if you can get someone to sponsor the upload. If you're not familiar with Debian style packaging, file a bug report on Launchpad, link the upstream patch, and see if you can find someone interested. -- Richard -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Feature request: Could you make "Software Updater" download only the parts that have changed? Torrents divide a file into hashes and only download the missing parts. Could updates work in a simila
Please file feature requests in Launchpad, on the appropriate package. -- Richard > On Nov 30, 2019, at 14:42, Clinton H <49studeba...@gmail.com> wrote: > > Ubuntu 19.10 > > -- > Ubuntu-devel-discuss mailing list > Ubuntu-devel-discuss@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: ZFS feature flags
On 10/19/19 4:43 AM, Colin Watson wrote: > I don't have much to say about most of this, but noticed this bit: > > On Thu, Oct 17, 2019 at 09:48:42PM -0500, Richard Laager wrote: >> The same implementation could (and if I have my way, will) be used to >> provide a features=grub mask. This would be used for the boot pool >> (bpool) to limit it to the features supported by GRUB. This would avoid >> the dangerous message in "zpool status" which tells you to run "zpool >> upgrade" on your bpool which would then break booting from it. > > Isn't that a dubious and confusing way to spell it? I'm certainly open to a different name. > After all, like any > other ZFS implementation, GRUB's ZFS implementation has gained features > over time, and it wouldn't surprise me if it continued to do so. It > sounds like you'd need a set of versioned features for this as well as > for features=portable; but it's not clear how the decision of when to > promote a feature set to the unversioned level would be made, > particularly given GRUB's rather slow and unpredictable release cycle > and the widespread practice of backporting features by distribution > maintainers. The proposal, as I understand it, is that the unversioned features=portable is defined as the set of features common to all the latest releases of specific "tier 1" ZFS platforms: FreeBSD, illumos-gate*, Ubuntu LTS, and ZoL**. A feature is promoted into the unversioned features=portable when it is available in all of those platforms' latest releases. As new platform releases push out older releases, the set of common features expands and the definition of features=portable can be updated. * illumos-gate, which I think doesn't have releases, was going to use a time-based cutoff. ** In practice, unless Ubuntu backports something from git master or writes their own ZFS feature, Ubuntu LTS will always be a subset of the latest ZoL release. Thus, Ubuntu LTS will be the limiting factor for the common set, not the latest ZoL release. The versioned features=portable- are simply features=portable frozen in time on January 1 of . The versioned ones are not driving anything design-wise, so they are mostly irrelevant for this discussion. If people also want versioned grub-, that's trivial to do. I think there are two approaches to take for features=grub. Originally, I was thinking that features=grub would be the set of features that are supported by GRUB on the current system. This solves the `zpool status` / `zpool upgrade` issues for the boot pool, which is the main goal. However, that definition could hamper dual-booting scenarios, so features=grub should probably be similar to features=portable. It should be the set of features common to all the latest releases of specific "tier 1" ZFS platforms that use GRUB (specifically GRUB 2, not GRUB Legacy) as their bootloader. I don't think that FreeBSD uses GRUB, and neither illumos nor ZoL are whole distros, so in practice this is just Ubuntu LTS at the moment. It may be desirable to expand this to include other distros where root-on-ZFS is a thing, like Arch and Gentoo. In other words, features=grub should be the features supported by GRUB in the latest release of whichever distros people might realistically want to dual-boot off the bpool. Whether the feature arrives in Ubuntu 20.04's GRUB by GRUB release or distro backport is irrelevant. The only thing that matters is which features are supported. An additional subtlety is that GRUB opens the pool read-only, so every read-only feature is "supported" from a GRUB perspective. So what GRUB "supports" on, for example, Ubuntu 20.04 is the union of the features-for-write actually supported by GRUB in Ubuntu 20.04, plus all read-only compatible features supported by the kernel ZFS implementation on Ubuntu 20.04. (Dependencies have to kept in mind here. If feature X is read-only compatible but depends on feature Y which is not read-only compatible, and feature Y is not supported by GRUB, then feature X is not supported by GRUB.) -- Richard -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: ZFS feature flags
TL;DR: I think the installer should default to all features, so I think the current behavior is correct. I would support the installer gaining an option to default to a subset of features (e.g. using the future features=portable mechanism) to make the pool more portable. If the desktop GUI partitioning tool gains support for creating ZFS pools, I would like to see a similar option there, probably with the opposite default (i.e. defaulting to portable). I was asked to comment on this thread. I maintain the upstream root-on-ZFS HOWTO which was used as a starting point for the Ubuntu installer design. However, unless otherwise noted, my comments are my own and do not necessarily reflect a ZoL/OpenZFS consensus. An incrementing version number was simple. It worked great when ZFS development was centralized at Sun only. When they opened things up with OpenSolaris, it worked okay enough. But as ZFS development started happening in parallel at various companies and projects, it was no longer feasible to have a simple integer version number. If company A develops feature X as zpool version 29 and company B develops feature Y as zpool version 29, you have a problem. The feature flags allow for parallel development and for features to land on different platforms in any order. The "read-only compatible" flag on features is a nice detail, too. It allows using a lot more features on the boot pool than would otherwise be the case. A lot of new features originate in ZFS-on-Linux, but features also originate from Illumos and FreeBSD. (Oracle is not involved in OpenZFS development in any way. They continue to have their own, closed-source ZFS implementation on Solaris which is not interoperable with pool features at all.) A downside of parallel development is that not all platforms are guaranteed to have the same features, or land the features in the same order. So cross-platform compatibility is definitely more complicated now. If you care about cross-platform compatibility for a particular pool, you have to limit your enabled features to the common denominator among the platforms you wish to support with that particular pool. Alternatively, you can use a minimal set of old features, or even version=28, but then you miss out on useful enhancements. There has been recent (March 2019) talk upstream of adding a "features=portable" property. This would act as a feature mask, limiting the enabled features (on zpool create and zpool upgrade) to a set that is portable across "tier 1" OpenZFS platforms. The exact semantics of what counts as a "tier 1" platform was part of that discussion; the notes (remember this was March) say "FreeBSD (11.X), ZoL (0.7.X), illumos-gate (from 1 year ago)". Further discussion was that the latest Ubuntu LTS would be considered a "tier 1" platform. The idea is that the definition of features=portable would be rolling, with unchanging features=portable- (e.g. portable-2018, portable-2019) complementing it as another option. This would significantly simplify configuration of pool features, but is not yet implemented. The same implementation could (and if I have my way, will) be used to provide a features=grub mask. This would be used for the boot pool (bpool) to limit it to the features supported by GRUB. This would avoid the dangerous message in "zpool status" which tells you to run "zpool upgrade" on your bpool which would then break booting from it. If/when features=portable lands, it's probably reasonable to expose that in the installer for the root pool. This could be a checkbox, for example. It might read something like, "Disable some pool features to maximize compatibility with other OSes" or "Maximize compatibility with other OSes by disabling some pool features". The default could go either way, but based on the existing precedent and my assumption that the majority use case is a single OS install, I would have the installer _default_ to the "more features, less portable" trade-off. Those who want the "less features, more portable" trade-off could change the checkbox. I think there's a stronger argument for features=portable (or otherwise limiting features) as the default for data pools than for the root pool. Data pools are more likely to move between systems than a root pool. This would be especially true for something like an external hard drive. They're also likely to be larger, making pool rebuilds more burdensome. For a _new install_ on a root pool, the need for portable is far less; dual booting seems like the most obvious and important case, which is a good use case for the checkbox. If the desktop GUI partitioning tool gains support for creating ZFS pools, I think features=portable would be a reasonable default there (again with a checkbox), under the assumption that it is creating data pools. Whatever the default, there are obvious exceptions. For example, if/when the installer supports ZFS encryption, if the user selects encryption, the installer must enable the
