Re: Validation of keyring changes [was: Enhancing cross-distro collaboration via foreign archive keyring] availability
On Wed, Oct 16, 2024 at 9:13 AM Robie Basak wrote: > > On Wed, Oct 16, 2024 at 08:48:25AM -0400, Neal Gompa wrote: > > Question then: what makes archlinux-keyring or debian-*-keyring > > packages different from distribution-gpg-keys? Shouldn't both of them > > get kicked out of the Ubuntu archive for the same reason? > > This is not a valid comparison. I already covered this in a previous > reply[1]. Note though that I made no suggestion that any package should > get "kicked out". I was only referring to SRUs. > I know you didn't, but if they can't be updated ever, then they shouldn't be in the archive in the first place. Strictly speaking, keyring packages that cannot be updated are much worse than having them at all. It lures people into a false sense of security, especially around verifying the integrity of content using those keys. If we apply the same standard to all keyring packages used to manage and verify software, then keyring packages that cannot be updated need to be kicked out, because it's extremely important that they can be updated. Incidentally, as a member of distribution-gpg-keys upstream, my only real ask for any distribution shipping is to not fork the sources as part of packaging it. In Debian terms, that means don't use the typical git-buildpackage workflow that creates an exploded git source tree and merges a debian folder into that source tree. That makes it really hard to determine whether someone has mucked around with the sources as part of packaging it. If Ubuntu (or any distribution) decides to make it hard to update keyring packages, I would rather you didn't package it at all and remove them from the archive. It does a disservice to users of that distribution if they can't be updated post-GA. -- Neal Gompa (FAS: ngompa) -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Validation of keyring changes [was: Enhancing cross-distro collaboration via foreign archive keyring] availability
On Wed, Oct 16, 2024 at 7:56 AM Robie Basak wrote: > > I don't have anything further to add to this sub-thread. I think I've > made valid points about what our requirements should be to ensure that > changes to key material are done in a way that our users can trust, why > not doing so would reduce user security compared to what happens in > Debian, and justified my position. I've also made some suggestions on > how I think this can be implemented without too much pain. > > If you don't want to do those things, then my opinion is that these > changes are not suitable for SRU in Ubuntu. Question then: what makes archlinux-keyring or debian-*-keyring packages different from distribution-gpg-keys? Shouldn't both of them get kicked out of the Ubuntu archive for the same reason? -- Neal Gompa (FAS: ngompa) -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Proposal to make MariaDB the default MySQL variant in Ubuntu 25.04
On Thu, Sep 19, 2024 at 7:36 PM Otto Kekäläinen wrote: > > Hi Ubuntu devs, > > The MariaDB Server, a fork of MySQL created in response to it being > acquired by Oracle, has been the default MySQL variant in Debian since > 2016. Starting from Debian 9 "Stretch" in 2017, MariaDB has been the > only MySQL variant in stable Debian releases. The situation has been > similar in the Fedora and SuSE ecosystems — currently Ubuntu is the > only major Linux distribution that ships Oracle MySQL at all. > > I think it is now time for Ubuntu to follow suit and at least make > MariaDB the default in the Ubuntu 25.10 cycle, and potentially remove > MySQL in some later release. > > The 25.04 development cycle is not yet open, but I am submitting this > proposal now, as it would be an ideal time to plan and decide ahead, > and execute immediately at the start of the 25.04 dev cycle in early > November. > > For what it's worth, on the Fedora side, we no longer consider MariaDB and MySQL substitutable. The two platforms have now diverged enough that we've untangled them and now ship them both as equal SQL server offerings. I would recommend the same for Debian and Ubuntu. Quote from the Fedora Linux 40 Change[1]: > Since MySQL 8.0 and circa MariaDB 10.5, the differences grew significantly > and so it does not make sense anymore to provide 'mysql' names > (= 'mysql' RPM Provides: ) by MariaDB package(s). IMO, it is not worth it to maintain the illusion that MariaDB is a "MySQL" implementation anymore. [1]: https://fedoraproject.org/wiki/Changes/F40_MariaDB_MySQL_repackaging -- Neal Gompa (FAS: ngompa) -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Enhancing cross-distro collaboration via foreign archive keyring availability
On Wed, Sep 4, 2024 at 8:48 AM Andreas Hasenack wrote: > > Hi, > > On Wed, Sep 4, 2024 at 7:27 AM Luca Boccassi wrote: >> >> Hi, >> (...) >> Given all of this, the costs appear minor, especially compared to >> other updates that are part of point releases. Is there perhaps some >> angle or detail that I am missing here? I appreciate Robie > > > I think one cost that may be missing from this analysis is the burden of > responsibility in the case of revoked keys. Should a key be revoked in, say, > Fedora, Fedora users can obviously expect an expedited update to the keyring. > But will the Fedora maintainers (again, just an example, pick $distro) > remember to also propagate this update to every other non-fedora distro? For Fedora, distribution-gpg-keys is a prerequisite for the core packager/developer workflow, and if the key were to be revoked and replaced, it gets put into that package pretty much immediately. Otherwise, people's local package builds start failing. -- Neal Gompa (FAS: ngompa) -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Enhancing cross-distro collaboration via foreign archive keyring availability
On Wed, Sep 4, 2024 at 6:27 AM Luca Boccassi wrote: > > Hi, > > For developers like myself who work across distributions, it is very > valuable to have a secure, simple and transparent way to bootstrap one > distro from another without relying on external trust anchors that > have to be verified manually. > > This is exemplified by the presence of $distro keyrings in > $other_distros. For example, the Ubuntu keyring is available in > Debian, Arch, Gentoo and others. The Debian keyring is available in > Ubuntu, Fedora, CentOS and others. This allows one to run debootstrap, > or dnf, or zypper, or pacman natively on a distro, knowing that the > chain of trust is verified like any other package shipped by your > distro, and get a root filesystem of another distro. This is > especially useful for image building tools. > > This requires updating the keyrings from time to time. For example, > until recently the Ubuntu keyring was outdated in Debian, and after > lots of nagging :-) Dimitri updated it (thanks Dimitri!). As another > example, Fedora does 2 releases a year, and each one requires a > keyring update as a new key is used for a new release. > > We are now in such a time of the year, as a new Fedora release is > being prepared. So I filed a Launchpad bug, and asked a patch pilot > for help and Lena kindly helped with the task (thanks Lena!). This was > uploaded as an SRU (note that I'd be fine with stable-backports too, > but I do appreciate the extra effort of course). > > At this point an objection was raised Robie, quoting directly from Launchpad: > > "I'm declining to process these without consensus amongst Ubuntu > developers that constant SRUs of these packages is the right > architecture to use." > > As far as I can understand, the concern seems to be around future > maintenance costs. All keyring packages are the same: they ship a set > of keys, with no running code, or scripts, or build required, simply > move a set of files into a package and ship it. They are all > maintained in git, on Salsa. Updates means new keys are added upstream > by the respective owners - Debian keyring owners, Ubuntu keyring > owners, Archlinux keyring owners, RPM distro keyring owners. The > package structure is extremely unlikely to change. Regressions are > likewise unlikely: there is no running code, neither at build time nor > at runtime. > As the maintainer in Debian, I am ok with preparing and testing these > updates, before asking for a sponsored upload. > > It is also important to note that these are separate and independent > packages, maintained independently by different people, the actual > owners of each keyring - and it's important that it's the owner of the > keyrings that manage them, for trust reasons - imagine if someone who > is not an Ubuntu developer or a Canonical employee was sending around > the Ubuntu key, asking others to trust it! It would not be, let's say, > an optimal arrangement. The RPM distros are quite good at > collaborating, so distribution-gpg-keys is the single source that is > needed for all RPM based distros. Ubuntu, Debian and Arch each have > their own repository, independently, so independent packages are > needed. > > Given all of this, the costs appear minor, especially compared to > other updates that are part of point releases. Is there perhaps some > angle or detail that I am missing here? I appreciate Robie > double-checking that this is the right way to do it. I hope I was able > to explain that the architecture is the one commonly used and would > expect adding a different Ubuntu-only alternative would likely be a > costly approach, for little benefit. Therefore I wanted to ask if we > can agree on this kind of sporadic updates being ok? If it is helpful > we could even draft something to be added to > https://wiki.ubuntu.com/StableReleaseUpdates#Documentation_for_Special_Cases > so anyone involved in the future can refer to it more easily. > > Thanks! > > https://bugs.launchpad.net/ubuntu/+source/distribution-gpg-keys/+bug/2075505 > https://bugs.launchpad.net/ubuntu/+source/archlinux-keyring/+bug/2076416 > https://tracker.debian.org/pkg/distribution-gpg-keys > https://tracker.debian.org/pkg/archlinux-keyring > At least with distribution-gpg-keys, it might help with the churn if the "distribution-gpg-keys-copr" package was not shipped in Debian or Ubuntu. I don't ship it in openSUSE either[1]. [1]: https://code.opensuse.org/package/distribution-gpg-keys/blob/master/f/distribution-gpg-keys.spec -- 真実はいつも一つ！/ Always, there's only one truth! -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: move to deb822 sources in ubuntu:lunar docker image
On Tue, Jan 17, 2023 at 3:19 PM Colin Watson wrote: > > On Mon, Jan 16, 2023 at 05:30:27PM +0100, Thomas Bechtold wrote: > > So my understanding is, that we would need to adjust live-build and/or > > livecd-rootfs to use the deb822 format. And if we do that, would > > we also need to adjust launchpad-buildd to handle the new format, too? > > I don't think we can reasonably switch to writing out the new format > from launchpad-buildd in the short term; it would require some > not-quite-trivial changes to Launchpad as well, and we're short-staffed > at the moment with a lot of other stuff going on, so taking on more > refactoring work doesn't really appeal. We've also recently dispatched > builds for trusty (though I didn't check exactly why), and I believe its > apt is too old to support the deb822 format, so we need to retain > compatibility with it for a while longer. > I believe it was introduced in APT 1.1, which means it was first made available to Ubuntu users with Ubuntu 16.04. > The simplest change might be to make launchpad-buildd ensure that the > new default sources.list path (/etc/apt/sources.list.d/ubuntu.sources?) > doesn't exist, and then just write out the old format to sources.list as > before. > > I definitely anticipate lots of breakage from this change! I hope all > the effort will be worth it. > Having a more comprehensible apt source configuration is definitely worth it. :) -- Neal Gompa (FAS: ngompa) -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Upgrade Notifications for Kubuntu and Ubuntu Studio
On Thu, Sep 8, 2022 at 6:29 AM Harald Sitter wrote: > > https://invent.kde.org/system/distro-release-notifier may help > > On Thu, Sep 8, 2022 at 3:09 AM Erich Eickmeyer wrote: > > > > Hi all, > > > > > > In Kubuntu and Ubuntu Studio, we rely on Discover and the Discover Notifier > > to run our GUI-based package updates. I don't care if you personally use > > apt periodically from the terminal, a case can be made that we expect our > > users to use Discover to do their updates. > > > > > > Unfortunately, Discover is very, very flawed. It uses packagekit as its > > backend and its upgrader is designed to do one thing: upgrade packages. By > > comparison, the Ubuntu Update Manager will give the user the option to > > remove unused packages, unused kernels. and even notify of new Ubuntu > > releases, which is something that Discover cannot do since it's built to be > > as distribution-agnostic as possible. Plasma Discover *can* support all these things. That is dependent on the PackageKit backend and whether your distribution ships AppStream metadata to identify your operating system and its upgrade path. This is something that is being worked on for Fedora KDE, so I'm aware of the possibility. -- Neal Gompa (FAS: ngompa) -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: New Ubuntu Core Developers - Olivier Tilloy and Sergio Durigan Junior!
On Tue, Nov 3, 2020 at 4:52 AM Lukasz Zemczak wrote: > > Hello everyone, > > After yesterday's DMB meeting, please congratulate our two new Ubuntu > core-dev members: oSoMon and sergiodj! Welcome to the team! > Congratulations! :) -- 真実はいつも一つ！/ Always, there's only one truth! -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Call for nominations: Developer Membership Board
On Sat, Feb 8, 2020 at 8:33 PM Robie Basak wrote: > > On Fri, Feb 07, 2020 at 11:38:19PM +, Seth Arnold wrote: > > Can we replace the meeting with something else entirely, something that > > fits better into the schedules of distributed, busy, people? > > Absolutely. The DMB can change how they process applications as they > wish. > > There has been talk changing the schedule. I have always suggested that > the board members who have difficulty attending the current meetings > should drive that, as any change is pointless unless it actually helps > the regular absentees attend more often. Unfortunately this never > happened. > > Perhaps one process change could be that one of the newly elected DMB's > first tasks is to decide and ratify the meeting schedule, to ensure it > is suitable for them. This is actually how it's done in Fedora. When a new group of members is elected, the first order of business is determining what is the best time for *that* group of members. Every FESCo, FPC, Council, etc. group winds up refreshing their meeting times on the first meeting post-elections. -- 真実はいつも一つ！/ Always, there's only one truth! -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: RFC: baseline requirements for Ubuntu rootfs: xattrs and fscaps
On Mon, Aug 6, 2018 at 5:53 PM Steve Langasek wrote: > > Hi John, > > On Mon, Aug 06, 2018 at 10:09:53PM +0100, John Lenton wrote: > > On Mon, 6 Aug 2018 at 21:16, Steve Langasek > > wrote: > > > > I think it's exceedingly unlikely that anyone is going to unpack, and > > > subsequently boot, an Ubuntu root tarball on a filesystem that doesn't > > > support xattrs. All the filesystems that Ubuntu supports out of the box > > > as > > > rootfs (in terms of installers, and filesystem tools preinstalled) support > > > xattrs. > > > while this is strictly true, 'snap pack' and 'snapcraft pack' > > currently disable xattrs, and the store will not approve snaps that > > are built with xattrs. > > Thanks, that's a useful data point. Do you think it is a practical concern > for snaps if an Ubuntu rootfs uses fscaps? Is this an argument against > allowing fscaps in Ubuntu, or should it just be a matter for snapcraft to > warn/error about on creation, guiding users to using setuid instead? > > As a worked example: the core snap does ship /bin/ping, which is currently > setuid-root in Ubuntu but would move to fscaps in this proposal. (The core > snap does not include mtr-tiny.) What do you believe is the correct outcome > here for /bin/ping in a future ubuntu core 20 snap? > The upcoming Fedora base snap is likely to require maintaining xattrs, since we heavily use fscaps, among many other things. So this requirement will likely change. -- 真実はいつも一つ！/ Always, there's only one truth! -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Ubiquity NG - was Re: ubiquity migrated to git
On Thu, May 10, 2018 at 4:29 AM Bryan Quigley wrote: > On Tue, May 8, 2018 at 7:31 PM, Simon Quigley wrote: >> Hello Mark, >> On 05/05/2018 01:15 AM, Mark Shuttleworth wrote: >> >> > First, we have Curtin, which knows how to take a description of a >> > machine and do-the-right-thing; partitioning, installing, and cleaning >> > up. Curtin is neat and efficient, super-fast, and it's used by both MAAS >> > and the new Ubuntu Server installer, Subiquity. It knows how to install >> > a couple of different flavours of Linux, including Ubuntu and CentOS, >> > which could be handy. It's probably the best place for us to handle new >> > kinds of partitioning and root filesystem and network storage. >> > >> > Second, we have MAAS, which has some very nice HTML interfaces for >> > configuring network and storage on a machine. All of that lines up with >> > Curtin, because MAAS uses Curtin to do the actual install. So we have >> > the beginnings of an HTML5 installer. >> Would we be able to customize this in a way that's fit for desktop users >> rather than server users? A fork might need to happen there. > There are no technical reasons why MAAS/Curtin can't be used for desktop installs. > I'm not sure how much sense it makes to reuse the MAAS UI bits though.. We only ask for network bits if you are not connected to a wireless network. > I'd love if we at least move to subiquity/curtin because that means we have to > publish desktop MAAS images which has been something I've been pushing for a while now [1]. > This would push us in the direction of "one" best practice way to install Ubuntu on almost everything. > It may even be possible with subiquity to have a text based fallback on a normal live image. If possible > this might allow an Alternate style install (like Lubuntu has) for all flavors for free. >> > Third, we have Electron, which is the HTML5 app framework used by world >> > class app developers. Skype, Spotify and a ton of GREAT apps on Ubuntu >> > are Electron apps. >> I respectfully disagree that this is the correct approach for a system >> installer. With all due respect to these very popular applications, >> Electron uses quite a bit of system resources and could be interesting >> to get working correctly. If you are absolutely certain that this is the >> way to go, I won't argue this point too much, but I believe that you >> would have triple the speed (and/or it would use a third of the memory) >> by writing a native application rather than an Electron one, and with >> proper testing and organization (perhaps by using a compiled language >> rather than an interpreted one, etc.), it would be a very welcome speed >> jump over the current Ubiquity codebase. > Additionally, we'd have to bring Chromium up to the requirements (snappy edition) for Main. (which I wouldn't mind, but doesn't make sense just for this) The Korora guys were considering adding a web-based desktop frontend to Anaconda a few years ago, and developed the Lens framework[1][2] for that purpose. It's a much more lightweight alternative that also supports some level of integration for Qt and GTK+ based desktop environments. [1]: https://kororaproject.org/about/news/lens-an-alernative-to-desktop-agnostic-uis [2]: https://github.com/kororaproject/kp-lens -- 真実はいつも一つ！/ Always, there's only one truth! -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: zstd compression for packages
On Mon, Mar 12, 2018 at 10:09 AM, Julian Andres Klode wrote: > On Mon, Mar 12, 2018 at 09:30:16AM -0400, Neal Gompa wrote: >> On Mon, Mar 12, 2018 at 9:11 AM, Daniel Axtens >> wrote: >> > Hi, >> > >> > I looked into compression algorithms a bit in a previous role, and to be >> > honest I'm quite surprised to see zstd proposed for package storage. zstd, >> > according to its own github repo, is "targeting real-time compression >> > scenarios". It's not really designed to be run at its maximum compression >> > level, it's designed to really quickly compress data coming off the wire - >> > things like compressing log files being streamed to a central server, or I >> > guess writing random data to btrfs where speed is absolutely an issue. >> > >> > Is speed of decompression a big user concern relative to file size? I admit >> > that I am biased - as an Australian and with the crummy internet that my >> > location entails, I'd save much more time if the file was 6% smaller and >> > took 10% longer to decompress than the other way around. >> > >> > Did you consider Google's Brotli? >> > >> >> I can't speak for Julian's decision for zstd, but I can say that in >> the RPM world, we picked zstd because we wanted a better gzip. >> Compression and decompression times are rather long with xz, and the >> ultra-high-efficiency from xz is not as necessary as it used to be, >> with storage becoming much cheaper than it was nearly a decade ago >> when most distributions switched to LZMA/XZ payloads. > > I want zstd -19 as an xz replacement due to higher decompression speed, > and it also requires about 1/3 less memory when compressing which should > be nice for _huge_ packages. > On a pure space efficiency basis, zstd -19 is still not as good as xz -9, but it's pretty darned good. >> I don't know for sure if Debian packaging allows this, but for RPM, we >> switch to xz payloads when the package is sufficiently large in which >> the compression/decompression speed isn't really going to be matter >> (e.g. game data). So while most packages may not necessarily be using >> xz payloads, quite a few would. That said, we've been xz for all >> packages for a few years now, and the main drag is the time it takes >> to wrap everything up to make a package. > > We could. But I don't think it matters much. > Maybe not. It was useful a long time ago, now we don't really care either, as we use xz across the board (for the moment). >> >> As for Google's Brotli, the average compression ratio isn't as high as >> zstd, and is markedly slower. With these factors in mind, the obvious >> choice was zstd. >> >> (As an aside, rpm in sid/buster and bionic doesn't have zstd support >> enabled... Is there something that can be done to make that happen?) > > I'd open a wishlist bug in the Debian bug tracker if I were you. If > we were to introduce a delta, we'd have to maintain it... > Hence asking about sid/buster and bionic. :) My previous experience with debbugs is that it's a black hole. We'll see if it's better this time. -- 真実はいつも一つ！/ Always, there's only one truth! -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: zstd compression for packages
On Mon, Mar 12, 2018 at 9:11 AM, Daniel Axtens wrote: > Hi, > > I looked into compression algorithms a bit in a previous role, and to be > honest I'm quite surprised to see zstd proposed for package storage. zstd, > according to its own github repo, is "targeting real-time compression > scenarios". It's not really designed to be run at its maximum compression > level, it's designed to really quickly compress data coming off the wire - > things like compressing log files being streamed to a central server, or I > guess writing random data to btrfs where speed is absolutely an issue. > > Is speed of decompression a big user concern relative to file size? I admit > that I am biased - as an Australian and with the crummy internet that my > location entails, I'd save much more time if the file was 6% smaller and > took 10% longer to decompress than the other way around. > > Did you consider Google's Brotli? > I can't speak for Julian's decision for zstd, but I can say that in the RPM world, we picked zstd because we wanted a better gzip. Compression and decompression times are rather long with xz, and the ultra-high-efficiency from xz is not as necessary as it used to be, with storage becoming much cheaper than it was nearly a decade ago when most distributions switched to LZMA/XZ payloads. zstd also provides the necessary properties to make it chunkable and rsyncable, which is useful for metadata. For package payloads, there are things we can do to make compression go much faster than it does now (and it's still quite a bit faster than xz as-is and somewhat faster than gzip now). I don't know for sure if Debian packaging allows this, but for RPM, we switch to xz payloads when the package is sufficiently large in which the compression/decompression speed isn't really going to be matter (e.g. game data). So while most packages may not necessarily be using xz payloads, quite a few would. That said, we've been xz for all packages for a few years now, and the main drag is the time it takes to wrap everything up to make a package. As for Google's Brotli, the average compression ratio isn't as high as zstd, and is markedly slower. With these factors in mind, the obvious choice was zstd. (As an aside, rpm in sid/buster and bionic doesn't have zstd support enabled... Is there something that can be done to make that happen?) -- 真実はいつも一つ！/ Always, there's only one truth! -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: aptdaemon
On Wed, Mar 15, 2017 at 3:44 PM, Barry Warsaw wrote:
> I believe aptdaemon is effectively abandoned. It's been removed from Debian
> but it's still hanging around in Ubuntu due to a few reverse dependencies:
>
> % reverse-depends aptdaemon
> Reverse-Depends
> ===
> * gnome-software
> * language-selector-gnome
> * oem-config-gtk
> * python-aptdaemon
> * python3-aptdaemon
> * sessioninstaller
>
> I think the gnome-software dependency is unnecessary. I can't find a
> reference to aptdaemon in the source, and I built a version without it in my
> PPA, tested it in a Zesty VM and it worked fine afaict. I've prepared a
> version that's ready for upload, which I'd like to do unless someone with more
> knowledge about it objects. (OTOH, it's not urgent so it can wait until after
> Zesty.)
>
> That leaves three remaining dependencies (ignoring python{,3}-apdaemon) all of
> which appear legitimate. Note that language-selector-gnome, oem-config-gtk,
> and sessioninstaller are only in Ubuntu, not in Debian, and each still have
> their own reverse dependencies.
>
> I bring this up because back in January, I uploaded aptdaemon
> 1.1.1+bzr982-0ubuntu17 which was a contributed fix for LP: #1623856; a problem
> with the minimum window height. I thought I'd tested the build at the time,
> but I got distracted with other things, and was reminded today that it's
> *still* in -proposed because its failing its tests. I don't think those tests
> are fixable without a fair bit of work since afaict, they are using obsolete
> APIs that no longer exist. The version before mine was last uploaded in
> Yakkety, and even trying to build the Yakkety version in Zesty fails. So my
> changes (as expected) aren't relevant and the package is simply no longer
> buildable in Ubuntu. Yay for TIL.
>
> Given the state of aptdaemon, I think it's in Ubuntu's interest to drop it,
> but that means porting or dropping language-selector-gnome, oem-config-gtk
> (src:ubuquity), and sessioninstaller. I don't know what the states of those
> packages are, so the best I can do is file bugs against them.
>
> Given where we are in the Zesty cycle, I recommend just dropping aptdaemon
> 1.1.1+bzr982-0ubuntu17 from -proposed and marking LP: #1623856 as Won't Fix.
> Let's try to drop aptdaemon from Ubuntu in Acrobatic Aardvark.
>
So, sessioninstaller is an aptdaemon based implementation of the
PackageKit session interface. The two can be dropped together, since
they are both unmaintained and not needed. PackageKit provides
everything needed as a replacement.
The dependency by gnome-software is illusory, as it depends on
PackageKit D-Bus interfaces (provided by PackageKit). The dependency
wasn't even present in xenial, as far as I recall...
oem-config-gtk is a single script[1] with only a few lines of code
actually using aptdaemon, and that can be ported to use PackageKit
instead.
language-selector-gnome is similar[2], and should be easy to port out
to PackageKit, assuming this is even needed anymore. It doesn't look
like it's maintained either...
[1]:
http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/view/head:/bin/oem-config-remove-gtk
[2]:
http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/vivid/language-selector/vivid/view/head:/LanguageSelector/gtk/GtkLanguageSelector.py
--
真実はいつも一つ！/ Always, there's only one truth!
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Dropping LXC backend from Ubuntu's libvirtd
On Wed, Dec 7, 2016 at 3:49 AM, Stéphane Graber wrote: > Hey there, > > Ubuntu's libvirt currently ships with its own Linux Containers > implementation (confusingly called libvirt-lxc). > > This code has nothing to do with upstream LXC, confuses users who expect > that it does and is in general a much worse experience that the one we > provide through LXD in Ubuntu. > > We'd rather not have to maintain that feature in main and given that > libvirt backends can't be split into separate packages (at least > trivially), we're now looking at turning libvirt-lxc altogether. > > Red Hat, who was the main driver for this particular driver has also dropped > support for it back in March 2015[1] (in favor of Docker support). > > > If you are a current user of libvirt-lxc, we'd be very interested to > hear from you about your use case for it, especially about anything > which libvirt-lxc is providing which you can't achieve with LXC/LXD. > > Thanks! > > [1] https://access.redhat.com/articles/1365153 > This is news to me, because in Fedora, we *do* ship the libvirt-lxc driver as a separate subpackage[1], and we have for a very long time. Also, libvirt definitely did not drop support for LXC, and it's still offered in Fedora. Red Hat has decided to drop it from Red Hat Enterprise Linux, but that doesn't mean that it's not still available and maintained. [1]: http://koji.fedoraproject.org/koji/buildinfo?buildID=822727 -- 真実はいつも一つ！/ Always, there's only one truth! -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Only one qt version on the Ubuntu Desktop iso?
On Fri, Mar 18, 2016 at 1:21 PM, Sebastien Bacher wrote: > Hey there, > > The only reason the Xenial Ubuntu Desktop iso currently has qt4 still > included is because the "integration components for softwares using that > toolkit" are Recommends (appmenu-qt, sni-qt, fcitx-frontend-qt4). > > The default installation has no actual use for those but removing them > would mean that an Unity user installing some qt4 software wouldn't get > integrated menus/indicators/input method. > > We could make qt4 recommends them, but then they would be pulled in on > other desktops environment where they are not needed ... how would other > flavors feel about that? > If that's not an option does somebody have a better suggestion/idea how > we could get those installed for Unity users when required? > > Unsure if that's still something we might still want to do this cycle, > I'm at least mentioning it in case somebody feels like working on those > changes... > Isn't Qt 4 EOL now? Why not move Qt 4 stuff to universe? -- 真実はいつも一つ！/ Always, there's only one truth! -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Knocking Python 2 off the desktop iso
On Thu, Mar 10, 2016 at 1:17 PM, Dmitry Shachnev wrote: > Hi Sebastien, > > On Tue, Mar 08, 2016 at 08:08:35PM +0100, Sebastien Bacher wrote: >> Hey Barry, >> >> Le 08/03/2016 17:36, Barry Warsaw a écrit : >> > I know this makes things less friendly for people who need Windows >> > resources, >> > but until Samba itself gets fully ported, our choices are rather limited: >> > keep >> > two Python stacks on the desktop image or provide a hook to install the >> > required packages when needed. >> >> Do we plan to reduce/drop support for python2.7 if we get it out of the >> iso? Or what's the direct result out of those efforts out of sending a >> message and winning some CD space? > > In my opinion "sending a message" is a quite a big result. Currently even > developers of new apps sometimes consider using Python 2 because it "works > out of the box everywhere" unlike Python 3 (which may not be present on some > old distros). If we ship LTS with Python 3 only, this will be no longer the > case. I.e. it will make the world moving to Python 3 a bit faster. > > And the earlier the world moves to Python 3, the earlier we will be able to > reduce/drop support for Python 2. > It's also important to note that the lifespan of Ubuntu 16.04 LTS does go past the Python 2 expected maintenance period (end of the decade). And as Ubuntu LTS is one of the most popular platforms for developers to use, it strengthens the case to push for Python 2 code to port over to Python 3. -- 真実はいつも一つ！/ Always, there's only one truth! -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
