Re: pastebinit default target on Ubuntu
On Mon, Apr 15, 2024 at 04:42:37PM -0400, Stéphane Graber wrote: > On Mon, Apr 15, 2024 at 4:14 PM Steve Langasek > wrote: > > And if there are issues with the usability of paste.ubuntu.com, uh, we own > > that service? So let's work with our IS team to make it fit for purpose. > > (I don't know why it currently requires a login to *view* paste contents; > > that seems straightforwardly a bug that we should just get sorted.) > > That's because pastebin servers are frequently abused as a way to get > free mass storage. > > It's not very practical to require login to post to a pastebin as the > whole point is for a tool like "pastebinit" to work without needing > user configuration as it's commonly used as a debug tool on cloud > instances and other random servers random than a user's personal > system. > > With that in mind, a bunch of folks noticed that you could abuse a > service like paste.ubuntu.com by pushing large files (base64 encoded > or the like) and then retrieve them with a very trivial amount of html > parsing (if no raw option is offered directly). I'll add that (from memory) it wasn't just being abused as free mass storage in general, it was very very dodgy stuff that required urgent takedown enforcement. We talked IS down from making it require a login to use the service at all and this was the compromise. -- Colin Watson (he/him) [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: +1 maintenance report
On Fri, Jan 26, 2024 at 06:31:39PM -0500, Sergio Durigan Junior wrote: > * celery > - Spent a long time investigating the Python 3.12 segfault that > happens when running dh_auto_test. I was able to obtain a usable > stacktrace. > - I'll file an upstream bug. I don't know if you ever did this, but in case it's still on your to-do list, this is https://github.com/python/cpython/issues/115874; I suggested a cherry-pick of the proposed patch there in https://bugs.debian.org/1063345. -- Colin Watson (he/him) [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: systemd-timesyncd depends on systemd?
On Fri, Jan 12, 2024 at 05:58:47PM +, David Crespi wrote: > We're having a problem getting systemd to load. Yesterday the system updated > the kernel, and everything went crazy. > It looks like systemd is only getting partially loaded now because > systemd-timesyncd is not being loaded. It looks like > timesyncd isn't being loaded because of a dependency on systemd. What's the output of "sudo dpkg --configure -a"? (This may fix it and return success, or it may return a bunch of errors. In the latter case the output will likely be interesting.) -- Colin Watson (he/him) [cjwat...@ubuntu.com] -- 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: Turning on phased update support in chroots in 24.10 (24.04?)
On Thu, Jul 13, 2023 at 12:47:40PM +0100, Dimitri John Ledkov wrote: > On Thu, 13 Jul 2023 at 11:42, Julian Andres Klode > wrote: > > Phasing is not affected by pinning you need to set: > > > > APT::Get::Always-Include-Phased-Updates "true"; > > Given this option already exists, we should just start setting it > explicitly in launchpad-buildd & mk-sbuild. launchpad-buildd has set this option since 2021. -- Colin Watson (he/him) [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: breezy behavior wrt lp: [Was Re: git-ubuntu build]
On Wed, Jun 14, 2023 at 08:54:23AM -0700, Steve Langasek wrote: > On Wed, Jun 14, 2023 at 03:29:11PM +0200, Paride Legovini wrote: > > What happens is that Breezy finds the lp: shorthand and resolves it to a > > Git URL, then fails if we were actually pointing it to a Bazaar repo. > > > For example this fails on my Mantic system if I use lp: for Git: > > > bzr branch lp:~ubuntu-core-dev/meta-release/ubuntu > > > I now use lpad: as a shorthand for Launchpad Git repos: > > > [url "ssh://par...@git.launchpad.net/"] > > insteadOf = lpad: > > I had encountered this behavior, but hadn't realized it was on account of my > own git config! > > For my part, I dug through the code and discovered that lp+bzr: > (undocumented AFAIK) works to force the use of bzr. Since I do a lot more > git checkouts that bzr from Launchpad these days (a trend that is only > likely to continue), this is what I'm sticking with, reserving the shorter > shortcut for git. My hero! I also mostly use git these days, but I still need to use bzr often enough that having to type out the full URL had become a noticeable annoyance. lp+bzr: definitely helps. -- Colin Watson (he/him) [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: NBS kernel removals: round two
On Tue, Jun 13, 2023 at 09:45:56PM -0700, Steve Langasek wrote:
> On Thu, Jun 01, 2023 at 12:55:36PM -0700, Steve Langasek wrote:
> > Consequently, I will be removing all kernel packages older than linux
> > 3.13.0-170.220 from trusty-{updates,security} next week.
>
> > I will leave xenial as-is for the moment, and send further mail before
> > making any changes to NBS packages there.
>
> Update: this has been done now.
>
> No reports have reached me of any users adversely affected by the removals
> of these old kernel binaries from trusty.
Entertainingly, while this may not have affected end users, from
circumstantial evidence we think this did manage to tickle a Launchpad
bug which has existed since May 2016:
https://bugs.launchpad.net/launchpad/+bug/2023698
Good to have the excuse to investigate that, since it's probably bitten
us occasionally in the past without quite causing enough problems to
make it worth tracking down!
--
Colin Watson (he/him) [cjwat...@ubuntu.com]
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: unixodbc-dev 2.3.11 seems broken
On Sat, Feb 11, 2023 at 10:13:13AM -0800, Robert Ayrapetyan wrote: > # lsb_release -a > No LSB modules are available. > Distributor ID: Ubuntu > Description:Ubuntu 20.04.5 LTS > Release:20.04 > Codename: focal > > > # apt show unixodbc-dev > Package: unixodbc-dev > Version: 2.3.11 This is not a package that comes from Ubuntu 20.04, and in fact it doesn't appear to have come from any version of Ubuntu at all (versions of unixodbc-dev provided by Ubuntu have some kind of suffix after the upstream version number - for example, the version in Ubuntu 22.10 is 2.3.11-2). Where did you get it from? The package is clearly broken, but that isn't an Ubuntu problem - perhaps you should reinstall the working version from Ubuntu. -- Colin Watson (he/him) [cjwat...@ubuntu.com] -- 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
Auto syncs from Debian fixed
On Tue, Jan 24, 2023 at 05:34:20PM +0100, Paride Legovini wrote: > Just a quick warning on the fact that Launchpad auto-syncs from Debian > to Lunar are currently not happening. > > There's an issue with debmirror is crashing [1], but the underlying > cause is on the Debian side [2]. > > The debian-ftp team is aware, hopefully that's going to be sorted out soon. The Debian ftpmasters have fixed the dak bug that caused this, and Launchpad's Debian import is running again now; auto-sync should catch up shortly after that. -- Colin Watson (he/him) [cjwat...@ubuntu.com] -- 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 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. 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. -- Colin Watson (he/him) [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Getting Invalid version exception during apt update
On Tue, Jan 03, 2023 at 12:04:34PM +0530, probal basak wrote: > I am getting the below exception while trying to issue apt update: > Getting this issue since last week. Previously the same thing used to work > perfectly fine. This is a bug in appimage-builder. As you can see from the fact that it's installed in /usr/local, it's not supplied by Ubuntu. The bug is that it's apparently trying to use the Python packaging.version library to parse and compare the version numbers of Ubuntu packages. Ubuntu package versions are not compatible with Python package versions, and it is incorrect to use Python's packaging.version library to do this job. It looks like this bug was fixed in https://github.com/AppImageCrafters/appimage-builder/pull/281, although it doesn't seem that there's been a release since that fix landed. I don't know how best to advise you to apply that fix to your system, but presumably you installed this program yourself and so have some idea of how best to upgrade it. -- Colin Watson (he/him) [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Setting NotAutomatic for hirsute+1-proposed
On Tue, Nov 01, 2022 at 12:22:00PM +0100, Steve Langasek wrote: > Unfortunately this discussion foundered on lack of consensus about whether > to make this change after the fact for stable series; which resulted in both > jammy and kinetic going out without this being set. > > I have set the flag now for lunar as it came up in discussion with > Foundations. The question of whether to change this for stable series is > still open (now with some further series that are stable) but can be > discussed separately. Cool, thanks. > Colin, will this flag be inherited in the future at series opening? Yes. -- Colin Watson (he/him) [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Second Jammy Jellyfish test rebuild
On Thu, Mar 24, 2022 at 07:44:11AM -0700, Erich Eickmeyer wrote: > I'm seeing a lot of failed arm64 builds without build logs. In the > past when I've seen this, I've merely retried the build and it has > succeeded. This shows a pattern in that it's likely we've got a buggy > build server. Yeah, this has been reported to us (Launchpad), but for the record we have no handle on a fix at present. The basic symptom is that buildd-manager timed out trying to poll the builder (probably over several attempts). This is either because the builder crashed or hung or something like that (possible under load, and sometimes particular builds will repeatedly OOM a builder or similar), or because of a network failure that meant we lost contact for too long, or because of a buildd-manager bug. Unfortunately it's extremely difficult even for us to tell which at present. Ubuntu test rebuilds tend to exacerbate this sort of thing, because the whole system is under significantly more load than usual. It's something that we'll keep trying to debug, but it's not as simple as a single buggy build machine, and so I want to set expectations that this may not be something we can fix quickly. -- Colin Watson (he/him) [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Bash Command "mkcd"
On Wed, Feb 23, 2022 at 02:39:28PM +, Pixelbog Pixi wrote: > I have a question: > Is it possible to add the command mkcd? > It stands for make & change directory and I think it will be super usefull. > > It happened already way too often that I typed "mk foo && cd foo" and > with mkcd it will save 8 keystrokes for the example "foo". > > I wrote a little script that gets every directory on my computer and found > out that the average > size of a directory 7.879865977982097 is. That means I would save on average > 12-13 keystorkes > for creating a dir and changing into it. > > Ofcourse I know you can write a function in .bashrc, but isn't it the same. Any such command would have to be a shell builtin; "cd" can't be implemented as a subprocess, because it needs to change a property (the current working directory) of the shell process calling it. It's also the sort of thing that would tend to attract requests for options, such as "-p" passed through to "mkdir -p". I'm not the bash maintainer, but the bar for new shell builtins is rightly high since any additions would affect all systems, and I would expect this to be refused since it's easy to implement it as a local shell function with whatever behaviour and spelling you want. -- Colin Watson (he/him) [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: [Launchpad-users] Proposed decommissioning of 32-bit powerpc builders in Launchpad
On Fri, Dec 03, 2021 at 12:59:34PM +, Colin Watson wrote: > The old 32-bit powerpc architecture was removed from Ubuntu in Ubuntu > 17.04 [1]. This means that all releases that still supported it are now > in ESM, and ESM doesn't include powerpc support. We're therefore > considering decommissioning Launchpad's powerpc builders. Note that the > 64-bit ppc64el architecture would be *unaffected* by this change. We've now disabled the powerpc architecture in xenial (which should cause no further builds to be created) and deactivated the powerpc builders. I plan to leave things in this state for a little while to confirm that no further powerpc builds are being created and that nothing else comes up, but after that we'll start tearing down the builders permanently. -- Colin Watson (he/him) [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: os-prober is disabled in grub 2.06 and where to go from here
On Fri, Dec 17, 2021 at 05:01:59PM +0100, Julian Andres Klode wrote: >We could run os-prober during install time, store the >output somewhere and then reuse the cached output in >grub-mkconfig. d-i at least used to have code to do exactly this (in grub-installer). I don't know/recall about our other installers. -- Colin Watson (he/him) [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Setting NotAutomatic for hirsute+1-proposed
On Mon, Dec 13, 2021 at 08:32:53AM -0500, Dan Streetman wrote: > Just to clarify, people won't need to manually specify all > dependencies, right? For example, if testing the 'systemd' package > from -proposed, simply doing 'apt install systemd/jammy-proposed' > would install the proposed version of systemd *and also* the proposed > version of libsystemd0? That's how it behaves in my tests, yes - if a dependency imposes a version constraint requiring a lower-priority version, then apt tries to satisfy it. > Also, is this really needed? Is it really so hard for people to just do: > > $ sudo add-apt-repository -p proposed > > ...install proposed package(s) normally and do tests... > > $ sudo add-apt-repository -r -p proposed This has been an issue on and off for at least a decade, so my impression is that we have solid empirical evidence that this is indeed too hard for many testers in practice. -- Colin Watson (he/him) [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Setting NotAutomatic for hirsute+1-proposed
On Wed, Feb 03, 2021 at 11:12:57AM +, Iain Lane wrote:
> I think the Launchpad support is still missing, although we started on
> this several years ago. That will need to be picked up and finished off:
>
> https://bugs.launchpad.net/launchpad/+bug/1016776
>
> That bug report talks about doing it pre-release (for devel only) but I
> think I'm now in favour of doing it always, and the proposed
> implementation in there would allow that. For devel, the main reason is
> that I frequently come across users who have misunderstood what proposed
> is for and manually enabled it themsleves, resulting in various degrees
> of brokenness on their systems and bug reports that take developers'
> time to triage and eventually close. These are not (always) people who
> have updated from a previous release, where we could have had tools
> disable -proposed for them, but also people who have explicitly turned
> it on after installing a daily out of an attempt to help test the
> upcoming release.
>
> On the client side, as Robie says, we will at least need to update
> documentation. I'm also not sure what update-manager will do if there
> are NotAutomatic updates present. It might need some tweaking to show
> them differently. This could be checked by looking at something in
> -backports, which is already present with these flags set.
>
> And finally, there's some implication for package builds; both Launchpad
> buildds and other builders would need to ignore this. Launchpad does
> this for -backports currently, i.e. -backports builds get Build-Depends
> from -backports wholesale; hoepfully that means the buildd side isn't
> too hard because we can reuse that.
This is now ready to use from the Launchpad point of view. There's a
"proposed_not_automatic" flag on distro series exported over the API; if
this is set to True, Launchpad writes "NotAutomatic: yes" and
"ButAutomaticUpgrades: yes" to the Release file. We've also arranged
for *-proposed to be pinned to 500 in launchpad-buildd, so Launchpad
builds will ignore this; I can't speak for other build environments.
Thus, from the Launchpad point of view this is ready to use, although
somebody may want to check the behaviour of things like sbuild and
pbuilder first.
Somebody in ~techboard would need to make the actual change, if you
think it's appropriate. For example, the following in "lp-shell
production devel" would do it for all supported Ubuntu series:
for name in ("bionic", "focal", "hirsute", "impish", "jammy"):
series = lp.distributions["ubuntu"].getSeries(name_or_version=name)
series.proposed_not_automatic = True
series.lp_save()
--
Colin Watson (he/him) [cjwat...@ubuntu.com]
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Proposed decommissioning of 32-bit powerpc builders in Launchpad
The old 32-bit powerpc architecture was removed from Ubuntu in Ubuntu 17.04 [1]. This means that all releases that still supported it are now in ESM, and ESM doesn't include powerpc support. We're therefore considering decommissioning Launchpad's powerpc builders. Note that the 64-bit ppc64el architecture would be *unaffected* by this change. There are some positive reasons for us to do this as well as simple cleanup. For a complicated chain of reasons, retaining powerpc support requires us to retain support for running launchpad-buildd on Python 2, which we could otherwise remove. There are also currently some problems with getting 32-bit powerpc VMs working on our latest POWER compute nodes; those may be fixable, but perhaps if we decommission the architecture then we wouldn't have to bother figuring out what the problem is. However, if we do this it will make it permanently impossible to run any powerpc builds (.deb packages, snaps, etc.) on Launchpad, and it's unlikely to be possible to undo this change. It therefore seems prudent to ask around: does anyone know of any reason why we might need to add powerpc support to Ubuntu 16.04 ESM, or otherwise retain any powerpc build capability in Launchpad? [1] https://lists.ubuntu.com/archives/ubuntu-devel-announce/2016-December/001199.html Thanks, -- Colin Watson (he/him) [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Jammy missing CNF data
On Mon, Nov 15, 2021 at 10:47:45AM -0800, Brian Murray wrote: > On Wed, Nov 10, 2021 at 11:48:15PM +0000, Colin Watson wrote: > > Looks like it's in the archive now. Thanks for tracking that down. > > Does anything need to be added to NewReleaseCycleProcess for this, or > > was it a one-off bug? > > It was a one-off bug because the prod-cnf-extractor machine was not up > to date, but I've now enabled unattended-upgrades so this specific type > of issue should not happen again. Having said that is there a mechanism > we could use to ensure the Commands files on the archive were generated > recently? Not at the moment. We could possibly throw ages of some files at Prometheus and then have an alert based on that, or something, but it might be easier to implement it in a Foundations-owned KPI somewhere? Anything we do would end up alerting either IS or Launchpad and we'd then have to hand it off to Foundations, which seems a bit indirect. -- Colin Watson (he/him) [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Jammy missing CNF data
On Wed, Nov 10, 2021 at 10:39:04AM -0800, Brian Murray wrote: > On Wed, Nov 10, 2021 at 08:11:19AM +0000, Colin Watson wrote: > > On Tue, Nov 09, 2021 at 02:22:34PM -0800, Brian Murray wrote: > > > I was looking at some Foundations bug reports[1] today and discovered that > > > there is no command-not-found information for Jammy as of yet. Looking > > > at the archive there is no cnf folder for any jammy components. Adding > > > the new release to the list of releases for the cnf-extractor was > > > done[2] (by me) so I'm at a loss for what is missing. Does anybody else > > > have an idea? > > > > Is cnf-extractor.internal still the current prod-cnf-extractor machine? > > It's not publishing any data for jammy either: > > I believe I've found the source of the problem and the system is > currently working on producing updated data for impish and after that > jammy will get done. Looks like it's in the archive now. Thanks for tracking that down. Does anything need to be added to NewReleaseCycleProcess for this, or was it a one-off bug? -- Colin Watson (he/him) [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Jammy missing CNF data
On Tue, Nov 09, 2021 at 02:22:34PM -0800, Brian Murray wrote: > I was looking at some Foundations bug reports[1] today and discovered that > there is no command-not-found information for Jammy as of yet. Looking > at the archive there is no cnf folder for any jammy components. Adding > the new release to the list of releases for the cnf-extractor was > done[2] (by me) so I'm at a loss for what is missing. Does anybody else > have an idea? Is cnf-extractor.internal still the current prod-cnf-extractor machine? It's not publishing any data for jammy either: cjwatson@anonster:~$ rsync -v cnf-extractor.internal::cnf-data/ receiving file list ... done drwxr-xr-x 4,096 2021/04/27 14:10:33 . drwxr-xr-x 4,096 2018/11/21 10:10:50 disco-backports drwxr-xr-x 4,096 2018/11/21 12:06:43 disco-proposed drwxr-xr-x 4,096 2018/11/21 12:12:56 disco-security drwxr-xr-x 4,096 2018/11/21 12:11:54 disco-updates drwxr-xr-x 4,096 2018/11/22 03:55:27 disco drwxr-xr-x 4,096 2019/04/24 07:30:01 eoan-backports drwxr-xr-x 4,096 2019/04/24 07:51:49 eoan-proposed drwxr-xr-x 4,096 2019/04/24 07:52:28 eoan-security drwxr-xr-x 4,096 2019/04/24 07:52:09 eoan-updates drwxr-xr-x 4,096 2019/04/24 12:03:02 eoan drwxr-xr-x 4,096 2019/10/25 05:23:49 focal-backports drwxr-xr-x 4,096 2019/10/25 05:29:33 focal-proposed drwxr-xr-x 4,096 2019/10/25 05:29:50 focal-security drwxr-xr-x 4,096 2019/10/25 05:29:42 focal-updates drwxr-xr-x 4,096 2019/10/25 07:57:25 focal drwxr-xr-x 4,096 2020/04/27 08:37:56 groovy-backports drwxr-xr-x 4,096 2020/04/27 08:45:58 groovy-proposed drwxr-xr-x 4,096 2020/04/27 08:46:18 groovy-security drwxr-xr-x 4,096 2020/04/27 08:46:08 groovy-updates drwxr-xr-x 4,096 2020/04/27 08:55:40 groovy drwxr-xr-x 4,096 2020/10/23 17:44:19 hirsute-backports drwxr-xr-x 4,096 2020/10/23 17:44:34 hirsute-proposed drwxr-xr-x 4,096 2020/10/23 17:44:57 hirsute-security drwxr-xr-x 4,096 2020/10/23 17:44:45 hirsute-updates drwxr-xr-x 4,096 2020/10/23 17:56:13 hirsute drwxr-xr-x 4,096 2021/04/27 12:48:08 impish-backports drwxr-xr-x 4,096 2021/04/27 14:10:03 impish-proposed drwxr-xr-x 4,096 2021/04/27 14:10:26 impish-security drwxr-xr-x 4,096 2021/04/27 14:10:15 impish-updates drwxr-xr-x 4,096 2021/04/27 14:24:09 impish sent 24 bytes received 843 bytes 1,734.00 bytes/sec total size is 0 speedup is 0.00 -- Colin Watson (he/him) [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Wget failures connecting to GitHub on Ubuntu 20
On Fri, Sep 17, 2021 at 09:15:12PM -0400, Jeffrey Walton wrote: > This caught me by surprise today: > > $ lsb_release -a > No LSB modules are available. > Distributor ID: Ubuntu > Description:Ubuntu 20.04.3 LTS > Release:20.04 > Codename: focal > > $ wget -O main.cxx > https://raw.githubusercontent.com/austin-clifton/cryptopp-chacha-asm-test/main/src/main.cpp This works fine for me on 20.04; perhaps the relevant DigiCert CA is disabled on your system. Try "sudo dpkg-reconfigure ca-certificates" and make sure it's enabled. -- Colin Watson (he/him) [cjwat...@ubuntu.com] -- 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: Submitting a request
On Thu, Sep 16, 2021 at 11:42:02AM +0200, Gunnar Hjalmarsson wrote: > On 2021-09-16 01:02, Steve Langasek wrote: > > Thanks for this insight! Based on the original post, it seems to me that we > > SHOULD retain ibus-m17n for Sinhala. Is this table in gnome-settings-daemon > > what ensures that it's retained? It's unclear to me how that works, > > gnome-settings-daemon is not what drives the installation and there are no > > references to 'm17n' in the ubiquity source. > > I think it is, without being able to point at the relevant code. At least it > works like that with the CJK languages, and it ought to work in the same way > with input languages supported by ibus-m17n. It has been a while, but I thought that this was controlled by /usr/share/language-selector/data/pkg_depends (in language-selector-common). ubiquity calls check-language-support to query for the packages it needs to keep. I don't see an "im:si::ibus-m17n" line in https://git.launchpad.net/~ubuntu-desktop/ubuntu/+source/language-selector/tree/data/pkg_depends. -- Colin Watson (he/him) [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: SBCL : building : Makefile : where to find?
On Tue, Jul 13, 2021 at 01:20:33PM +0200, em...@kathe.in wrote: > Where should I look to find the process (Makefile) used to build SBCL under > Ubuntu? > I tried look under http://in.archive.ubuntu.com/ubuntu but got disoriented > quite quickly. "apt source sbcl" and look in debian/rules. (dpkg-buildpackage calls debian/rules with various arguments to build binary packages from a source package.) -- Colin Watson (he/him) [cjwat...@ubuntu.com] -- 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: Quick Question
[Please use more informative subject lines if possible.] On Sat, Jun 26, 2021 at 09:06:15PM -0400, Drew Howden Tech wrote: > Quick question: if I create a new package to resolve a 'needs-packaging' > bug, should I put my name in the maintainer field of the control file, or > 'Ubuntu Developers'? It doesn't matter much. I lean towards your own. > Also, when patching/upgrading a package (to resolve a bug) should I > submit all the files (source package, resulting binary, etc.), or just > the debdiff/diff.gz? The debdiff (*not* just the .diff.gz - they aren't the same thing) is normally sufficient, although some reviewers may find it convenient to have a complete source package to download and perhaps sign/upload. If the fix involves a new upstream version then you should submit the full source package. It isn't generally necessary to submit binaries unless a reviewer specifically asks for them, and they wouldn't be used anyway, although of course you should have test-built your fix and confirmed that it actually works. -- Colin Watson (he/him) [cjwat...@ubuntu.com] -- 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: Application for Core Developer (gunnarhj)
On Mon, Apr 05, 2021 at 04:36:06PM +0100, Robie Basak wrote: > On Tue, Mar 23, 2021 at 11:19:48PM +0100, Gunnar Hjalmarsson wrote: > > I hereby apply to become a Core Developer. > > The DMB voted today to approve Gunnar's application. Congratulations, > Gunnar! What a fine addition to the team! Congratulations. -- Colin Watson (he/him) [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: dbgsym missing for focal-updates
On Tue, Mar 30, 2021 at 12:04:05PM -0400, Jesse Schwartzentruber wrote: > I noticed that the -dbgsym package versions lag behind what's available from > focal-updates. > > In particular, for libgtk 3.24 I see (from > http://ddebs.ubuntu.com/ubuntu/pool/main/g/gtk+3.0/): > > [ ] libgtk-3-0-dbgsym_3.24.18-1ubuntu1_amd64.ddeb 2020-04-19 13:50 > 8.0M > [ ] libgtk-3-0-dbgsym_3.24.23-1ubuntu1_amd64.ddeb 2020-09-11 18:42 > 8.2M > [ ] libgtk-3-0-dbgsym_3.24.25-1ubuntu3_amd64.ddeb 2021-03-25 16:44 > 8.5M > > These correspond to the latest releases for focal, groovy, and hirsute. The > latest for focal-updates is 3.24.20-0ubuntu1 and doesn't appear to be > present at ddebs. > > Is focal-updates supposed to have dbgsyms available? Yes. > Is there an expected time delay between version update and dbgsym > availability? There's a short expected time delay, but in this case the service is generally operating normally and gtk+3.0 3.24.20-0ubuntu1 was published nine months ago or so, so something is clearly wrong; our logs don't go back far enough to make it clear exactly what, though. Could you please file a bug on https://bugs.launchpad.net/ddeb-retriever/+filebug to remind us to look into it? -- Colin Watson (he/him) [cjwat...@ubuntu.com] -- 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: Found in https://packages.ubuntu.com/focal/i386/libasound2-dev/download
On Fri, Mar 26, 2021 at 10:43:41PM -0400, Tyler Foster wrote: > Package: libasound2-dev > Status: install ok installed > Priority: optional > Section: libdevel > Installed-Size: 660 > Maintainer: Ubuntu Developers > Architecture: i386 > Multi-Arch: same > Source: alsa-lib > Version: 1.2.2-2.1 > Provides: libasound-dev > Depends: libasound2 (= 1.2.2-2.1) > Suggests: libasound2-doc > Description: shared library for ALSA applications -- development files > This package contains files required for developing software > that makes use of libasound2, the ALSA library. > > > *Value should be 1.2.2-2.1ubuntu2.3 .* 1.2.2-2.1 was the version of that package in 20.04 at the time it released; we don't update what shows up in the unadorned "focal" suite after release. 1.2.2-2.1ubuntu2.3 was a post-release update, so that would be in the "focal-updates" suite (https://packages.ubuntu.com/focal-updates/i386/libasound2-dev/download) instead. packages.ubuntu.com is a very cumbersome way to actually fetch individual packages rather than just searching and browsing around though; you should instead use tools such as apt that will deal with resolving dependencies and fetching the correct version of the package for you. -- Colin Watson (he/him) [cjwat...@ubuntu.com] -- 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: General mechanism to supply "rich history" to git-ubuntu
ned repository, and then the importer would only point a ref at that once the upload has been processed? (I'm not sure how we would prevent an attacker from being able to force such a repository to grow without bound, though.) * Could we use merge proposals for this somehow? An upload is in some sense a proposal to merge some changes into the primary archive, and I know "git ubuntu submit" already integrates with merge proposals on an experimental basis. That might allow Launchpad to know that a given commit is interesting and should be made available - indeed we already have plans to expose virtual refs that correspond to merge proposals, although I don't think those are quite done yet. If we were to take this approach, then the ref that we point to could be made to appear in the target repository instead, which avoids the collection of issues around the source repository disappearing or moving. Of these, albeit with only half an hour's thought, I think my favourite is the last one: using merge proposals feels quite elegant, and is perhaps only a change in how your spec would be used rather than a format-level change. I may have missed something, though. What do you think? > Notably there's a Dgit field defined by Debian Policy against dsc files, > which is used for a very similar purpose[2]. I'm only a dgit user rather than an expert in its implementation, but I believe that the Dgit field is used by dgit to retrospectively work out the commit that represents a given source package version in the archive as part of preparing a newer version that ought to be a descendant of that commit, rather than as part of an upload instruction. That's why it lives in the .dsc file rather than the .changes: after an upload has been processed, the .changes is not stored in any authenticatable way. But it's true that the current specification of Dgit explicitly relies on the repository being at a well-known and persistent location. -- Colin Watson (he/him) [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Create a binary Debian package
On Mon, Jan 25, 2021 at 11:38:47AM -0800, Alex Chen wrote:
> Thanks for the information Colin. However, this is a binary package built
> from proprietary cross-platform source code.
> It is not open-source nor free software. There is no up-stream source
> package.
That doesn't matter for the purposes of my reply.
> > On Jan 25, 2021, at 6:51 AM, Colin Watson wrote:
> > On Sun, Jan 24, 2021 at 11:21:01PM -0800, Alex Chen wrote:
> >> I am trying to create a Debian package, i.e. a .deb file, that can
> >> install software in Ubuntu. I put a the following files under the build
> >> directory:
> >>
> >> build_dir/DEBIAN/control - Package configuration
> >> build_dir/DEBIAN/md5sums - MD5 checksums of every files to be installed.
> >> build_dir/DEBIAN/preinst postinst prerm postrm - Pre/Post installation
> >> and pre/post uninstallation scripts.
> >
> > You should never create files under DEBIAN/ directly. Build a proper
> > source package instead with the appropriate files under debian/, and
> > build binary packages from it using debuild. See for instance
> > https://wiki.debian.org/Packaging/Intro.
>
> It is not built from with 'configure' and 'make' from the source. The
> standard Linux build configuration does not apply.
> It is packaged with a script following the descriptions in
> https://www.debian.org/doc/debian-policy/ch-binary.html#binary-packages
> <https://www.debian.org/doc/debian-policy/ch-binary.html#binary-packages>
Source packages don't require the "standard Linux build configuration"
(there isn't really such a thing anyway, but rather a variety of common
build systems). They don't require configure or make, or indeed any
other build step. It's perfectly possible and commonplace to have a
source package that simply copies a bunch of prebuilt files into place,
or that runs pretty much whatever script you like.
None of this is a reason to construct the .deb by hand by poking into
DEBIAN/, and you'll just make trouble for yourself by doing so - you can
and should still use the normal packaging toolchain.
Also, another thing I just noticed: for dependencies on shared
libraries, you should normally use ${shlibs:Depends} in debian/control
rather than writing those exact dependencies out by hand. This makes it
easier to update the package to build correctly on newer versions of the
OS. You can't do this if you're building DEBIAN/control by hand - it's
a facility provided by the packaging toolchain.
> >> This what I have in the 'control' file
> >> =
> >> Package: test-package
> >> Version: 1.0.0
> >> Architecture: amd64
> >> Pre-Depends: coreutils, libicu60, libfontconfig1, firewalld, unzip, zip,
> >> curl, lapache2, apache2-bin
> >> ==
> >>
> >> I thought packages listed in Pre-Depends field of a control file are
> >> supposed to be installed by the system before it process the package
> >> itself, according to this document:
> >> https://www.debian.org/doc/debian-policy/ch-relationships.html#binary-dependencies-depends-recommends-suggests-enhances-pre-depends
> >>
> >> <https://www.debian.org/doc/debian-policy/ch-relationships.html#binary-dependencies-depends-recommends-suggests-enhances-pre-depends>
> >
> > Pre-Depends should only be used in rare circumstances. You should
> > normally use Depends instead. You also don't need to (and shouldn't)
> > explicitly depend on coreutils, since it's an essential package.
>
> In order for our software to function, several packages not usually present
> in a base system need to be installed first and according to the definition
> of 'Depends' and 'Pre-Depends', 'Pre-Depends' seems to be what is needed.
>
> Depends - Requires other packages it depends on to be 'unpackaged' or
> 'configured',
> 'Pre-Depends' - Requires 'dpkg' to complete 'installation' of these packages
> before event installing the package itself.
In general, the only reason you need Pre-Depends is if you're using the
dependency in question in your package's preinst script, and even that
is often a mistake that can be avoided. (There are occasional other
cases that really only come up if you're maintaining something that's a
core part of the OS itself. I'm familiar with what the Debian policy
manual says, and am summarising the essential points here since it's
often misunderstood.)
The Debian policy manual says "You should not specify a Pre-Depends
entry for a package before this has been discussed on the debian-devel
mailing list and a consensus about doing that has been reached", not
because of some kind of gatekeeping, but because Pre-Depends imposes
stronger constra
Re: Create a binary Debian package
On Sun, Jan 24, 2021 at 11:21:01PM -0800, Alex Chen wrote: >I am trying to create a Debian package, i.e. a .deb file, that can install > software in Ubuntu. I put a the following files under the build directory: > > build_dir/DEBIAN/control - Package configuration > build_dir/DEBIAN/md5sums - MD5 checksums of every files to be installed. > build_dir/DEBIAN/preinst postinst prerm postrm - Pre/Post installation and > pre/post uninstallation scripts. You should never create files under DEBIAN/ directly. Build a proper source package instead with the appropriate files under debian/, and build binary packages from it using debuild. See for instance https://wiki.debian.org/Packaging/Intro. > This what I have in the 'control' file > = > Package: test-package > Version: 1.0.0 > Architecture: amd64 > Pre-Depends: coreutils, libicu60, libfontconfig1, firewalld, unzip, zip, > curl, lapache2, apache2-bin > == > > I thought packages listed in Pre-Depends field of a control file are supposed > to be installed by the system before it process the package itself, according > to this document: > https://www.debian.org/doc/debian-policy/ch-relationships.html#binary-dependencies-depends-recommends-suggests-enhances-pre-depends > > <https://www.debian.org/doc/debian-policy/ch-relationships.html#binary-dependencies-depends-recommends-suggests-enhances-pre-depends> Pre-Depends should only be used in rare circumstances. You should normally use Depends instead. You also don't need to (and shouldn't) explicitly depend on coreutils, since it's an essential package. > I was able create the package with 'dpkg-deb --build build_dir' command > successfully, however I got the following dependency errors when I tried to > install the package in an Ubuntu server > > === > $ sudo dpkg -i test-package_1.0.0_amd64.deb > [sudo] password for tester > dpkg: regarding test-package_1.0.0_amd64.deb containing test-package, > pre-dependency problem: > test-package pre-depends on libfontconfig1 > libfontconfig1 is not installed. dpkg -i won't acquire or install dependencies that aren't yet installed; it only processes the files you give it. You can use this instead, which knows how to acquire and install dependencies as well as the specific file you give it (note that the "./" is important so that apt knows that you're talking about a file name rather than a package name): sudo apt install ./test-package_1.0.0_amd64.deb -- Colin Watson (he/him) [cjwat...@ubuntu.com] -- 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: ubiquity git repository
On Fri, Oct 09, 2020 at 07:34:05AM -0700, Brian Murray wrote: > On Fri, Oct 09, 2020 at 09:39:00AM +0100, Colin Watson wrote: > > ~canonical-foundations already has (force-)push access to that > > repository, so you personally can do this already without changing > > anything. > > Oh, that's neat but where is the fact that ~canonical-foundations can do > this discoverable? When I load the previously mentioned url I see the > following text: > > "You cannot push directly to this branch. Members of Ubuntu Installer > Team (ubuntu-installer) can push to this branch." Could you file a bug about that please? Maybe we didn't update that bit of UI to take per-branch permissions into account. -- Colin Watson (he/him) [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: ubiquity git repository
On Thu, Oct 08, 2020 at 09:17:46AM -0700, Brian Murray wrote: > Only the Ubuntu Installer Team[1] can push to the branch at > https://code.launchpad.net/~ubuntu-installer/ubiquity/+git/ubiquity/+ref/master. > Given that any core developer could upload ubiquity can we add Ubuntu > Core Developers to the Ubuntu Installer Team? This should only be done if ~ubuntu-installer's rather large set of bug subscriptions is pruned first, otherwise everyone in ~ubuntu-core-dev is going to get a *lot* of email. (Conversely, people in ~ubuntu-installer who actually rely on those subscriptions would need to subscribe themselves first; this rather awkward situation is why I never sorted it out years ago ...) Note that it's also possible to grant ~ubuntu-core-dev push access to that repository without adding them to ~ubuntu-installer; anyone in ~ubuntu-installer can configure this on https://code.launchpad.net/~ubuntu-installer/ubiquity/+git/ubiquity/+permissions. > Personally, I'd still submit pull requests as I'm not very familiar with > ubiquity but at least this way the reviewer could approve the change and > I could do the actual merge and upload. ~canonical-foundations already has (force-)push access to that repository, so you personally can do this already without changing anything. -- Colin Watson (he/him) [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Cfengine package
On Wed, Sep 30, 2020 at 09:39:09PM -0400, Kristopher Fisher wrote: > In the never ending attempt to harden my system security, I ran the > program Lynis, which instructed me to install a package called > CFEngine. In the process of installing this package, I couldn't help > bu notice that Ubuntu has the package's homepage listed as > http://www.cfengine.org, yet while trying to learn more before > installing, the only package I have been able to find via all search > engines, including Google , is page http://www.cfengine.com. Ubuntu's current packaging comes unmodified from Debian, and it looks as though Debian fixed this a little while back: https://salsa.debian.org/cfengine-team/cfengine3/-/commit/12c7780fd375b8651631afd179e45b67d1a8b8a6 So this is already fixed for the upcoming Ubuntu 20.10. Thanks, -- Colin Watson (he/him) [cjwat...@ubuntu.com] -- 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: Second Groovy Gorilla test rebuild
On Mon, Sep 28, 2020 at 06:07:08PM +0200, Matthias Klose wrote: > Some build failures on ppc64el and s390x are caused by a buildd issue, and > will > be retried soonish. Please ignore these where you see a ftbfs just on those > architectures, but successes on the other architectures. This should be fixed now. I think I've retried most of the affected builds, though I was doing this manually so it's certainly possible that I missed some. -- Colin Watson (he/him) [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: [Launchpad-users] Launchpad builder VMs upgraded to bionic
On Wed, Sep 16, 2020 at 12:02:48PM +0100, Dimitri John Ledkov wrote: > Are we using PAM today already? Cause on riscv64 builder I started to see > > E: PAM error: Authentication token is no longer valid; new one required > Chroot setup failed > E: Error creating chroot session: skipping openssl schroot may happen to use PAM, but it's not something we rely on as part of its interface - from our perspective that's an implementation detail. -- Colin Watson (he/him) [cjwat...@canonical.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Launchpad builder VMs upgraded to bionic
On Wed, Sep 16, 2020 at 10:22:05AM +0100, Dimitri John Ledkov wrote: > chroot builders do call ~= `sudo chroot` at some point. The main work is done by sbuild, which uses schroot, not "sudo chroot". (We used to use sbuild's sudo session mode, but I changed that to schroot in 2017.) > would changing limits.d + adding pam_limits to sudo pam config be > enough for launchpad-buildd? I think schroot does support PAM. However, I don't think it's good design for launchpad-buildd to rely on PAM, since after all it's not doing any kind of interactive authentication. I would rather not pursue this option any further. There are other less complicated ways to set resource limits. -- Colin Watson (he/him) [cjwat...@canonical.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Launchpad builder VMs upgraded to bionic
[Restoring CC of launchpad-users@ - not sure why this was dropped.] On Wed, Sep 09, 2020 at 03:25:04PM -0700, Steve Langasek wrote: > On Wed, Sep 09, 2020 at 10:33:00AM +0100, Dimitri John Ledkov wrote: > > I have not tried this, but i think one should be able to create a > > snippet in /etc/security/limits.d/ with like > > > * soft memlock unlimited > > * hard memlock unlimited > > > Or to the appropriate value of 64*1024 instead of unlimited. > > Which should only take effect for things which are part of PAM sessions that > have invoked pam_limits. I don't think this would be true for the builders? Correct - pam_limits isn't going to be involved here. Would something involving DefaultLimitMEMLOCK= do the job, maybe? -- Colin Watson (he/him) [cjwat...@canonical.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Launchpad builder VMs upgraded to bionic
On Tue, Sep 08, 2020 at 02:51:45PM -0300, Guilherme Piccoli wrote: > On Tue, Sep 8, 2020 at 1:48 PM Colin Watson wrote: > > Failing that, can somebody advise on whether there's an appropriate way > > to configure this in an image without having to maintain a fork of > > systemd? The workflow here is that we consume Ubuntu cloud images and > > make a few small changes to them, mostly things like installing > > launchpad-buildd, before publishing them to Glance for use when starting > > new builder VMs. > > I think the cloud image folks can chime in with good ideas, but I'd > consider cloud-init - likely it's possible to configure it in a way to > apply this change on boot time. Another idea: would it be possible to > change launchpad-buildd to accomplish the ulimit change ? Both of these are likely to be harder than just changing the image to add the appropriate bit of configuration, IMO. cloud-init makes sense when you're using unmodified cloud images, but we already have a pipeline for modifying images for our use; https://bazaar.launchpad.net/~canonical-sysadmins/canonical-is-charms/launchpad-buildd-image-modifier/view/head:/files/scripts/setup-ppa-buildd is the key bit here. (But I'd still need to know what exactly we need to set there.) I'd still like it to be fixed in bionic's systemd, even if we need to work around it in the short term. -- Colin Watson (he/him) [cjwat...@canonical.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: and autopkgtest hangs? Re: Build failures without a build log
On Wed, Aug 19, 2020 at 06:44:19PM +0100, Rebecca N. Palmer wrote: > Thanks - the retry worked for pandas and theano. > > statsmodels failed because it was temporarily BD-Uninstallable - this should > now be fixed, so please retry it if that doesn't happen automatically. Those particular kinds of failures aren't detectable automatically by the usual retry-depwait mechanism. I've retried them. > Could this have also affected autopkgtests? pandas is now being held in > -proposed because a snakemake autopkgtest hung: > https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#pandas > https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/amd64/s/snakemake/20200817_223057_9ce51@/log.gz I don't think so, but an autopkgtest person should probably have a look. (autopkgtest and Launchpad shares cloud infrastructure, but Launchpad doesn't operate autopkgtest as such.) -- Colin Watson (he/him) [cjwat...@ubuntu.com] -- 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: Build failures without a build log
On Tue, Aug 18, 2020 at 08:42:48AM +0100, Rebecca N. Palmer wrote: > (If this is an already known problem, where should I have checked before > reporting it? If it should be a bug report, against what?) > > Several packages say they failed to build, but do not have the build log > that would normally accompany this. > > Of the ones I uploaded recently (pandas, snakemake, statsmodels, theano): > pandas/arm64, armhf, ppc64el (with roughly the normal build duration) > statsmodels/armhf, ppc64el, s390x (s390x with an unusually long build > duration) > theano/ppc64el, s390x (with short build durations) > The same packages built successfully on Debian, but theano appears to be > BD-Uninstallable on Ubuntu. > > From the excuses "missing build" list: > dochelp/ppc64el > h5py/ppc64el > mate-applets/s390x > ghc/armhf > These are all less than 24 hours old (the builds, the ghc package is older); > I didn't find any older ones but I didn't check every entry. This was a Launchpad infrastructure issue; exact cause not completely clear but it looks like it was a networking problem in one of our datacentres. I've retried the affected builds now. -- Colin Watson (he/him) [cjwat...@ubuntu.com] -- 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
Launchpad builder VMs upgraded to bionic
The VMs in Launchpad's build farm have been on Ubuntu 16.04 (xenial) for some time. We're intentionally fairly conservative about upgrading the base VMs, but it's about time to have something newer, so we've just upgraded them to Ubuntu 18.04 (bionic). The actual builds still run in chroots or LXD containers of the appropriate Ubuntu series just as before, so most builds shouldn't notice any difference, but the kernel version is now 4.15 rather than 4.4. (As I type this, some VMs are still on xenial, but they'll be replaced with bionic once they're reset at the end of their next build.) The powerpc (as opposed to ppc64el) VMs are an exception to this: bionic doesn't include the powerpc architecture any more, so these will stay on xenial until such time as we no longer need to dispatch any powerpc builds and can decommission those builders entirely. Regards, -- Colin Watson (he/him) [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Dependencies of ubuntu-desktop
On Tue, Jul 14, 2020 at 05:16:20AM +0200, Andrei Rybak wrote: > Could someone please clarify why don't the packages ubuntu-desktop and > ubuntu-desktop-minimal depend on ubuntu-minimal? It's been a while, but IIRC we considered that many years ago and found that it seemed too annoying to do that in practice; it meant that if you were intentionally diverging from one part of the prescribed default system in such a way that required removing a lower metapackage, you ended up removing all the upper metapackages as well, and that ended up being rather a hassle. -- Colin Watson (he/him) [cjwat...@ubuntu.com] -- 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: Request: snap updating in Software Updater app
On Mon, Jun 08, 2020 at 12:52:55PM +0200, Bill Dietrich wrote: > In the Software Updater application, while checking/updating > snaps: > > - the Details button does not work > > - there is no percent-progress indicator shown > > Could someone please fix/improve these ? > > Should I file a feature-request somewhere, or is this > mailing list the only channel for that ? You can file bug reports (which include feature requests) for that application using "ubuntu-bug update-manager". -- Colin Watson (he/him) [cjwat...@ubuntu.com] -- 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: When will PHP be upgraded to 7.4.5 for focal?
On Tue, May 26, 2020 at 08:49:58PM -0300, Elias Soares wrote: > Can someone tell me when php releases are released to official repository > for focal? PHP 7.4.4 is out few a few months and is not available yet for > ubuntu 20.04 lts In general, stable releases of Ubuntu only get individually-selected bug fixes, rather than whole new releases. There are some exceptions, but I don't believe PHP is among them. See: https://wiki.ubuntu.com/StableReleaseUpdates If there's a specific high-impact bug that was fixed in this newer upstream release, please make sure it's filed in Launchpad. -- Colin Watson (he/him) [cjwat...@ubuntu.com] -- 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: groovy pre-open analysis | missing dists/groovy/cnf/
On Sun, Apr 26, 2020 at 09:36:01PM +0100, Dimitri John Ledkov wrote: > c-n-f service probably doesn't know about groovy yet. It is deployed > as a service on that autopkgtest juju environment. Not sure which > release, or how it gets distro-info-data updated to start generating > newer c-n-f data. Maybe it should be somehow "copied" up by launchpad > upon archive opening. I think it makes more sense to just get that service updated fairly early (it's in https://wiki.ubuntu.com/NewReleaseCycleProcess FWIW). Copying those files as part of series initialisation would be unnecessary extra code, since it isn't absolutely necessary for them to be copied in order for the series to work. -- Colin Watson [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: PT-BR translation
On Tue, Apr 14, 2020 at 09:13:48PM +0100, Colin Watson wrote: > On Sun, Apr 12, 2020 at 12:54:07PM -0400, Kinder wrote: > > How do I contribute to the ubuntu PT-BR translation? preferably the command > > "man"? > > Speaking as the upstream maintainer of man, the most long-term-effective > way to do this is to work with the Translation Project and thus > contribute the translations upstream > (https://translationproject.org/html/welcome.html). This work will be > shared with other distributions. Oh, this applies if you're talking about the localisation of the "man" command itself or the manual pages that are part of the man-db package. It doesn't necessarily apply if you're talking about other manual pages that you access using the "man" command. > The Ubuntu translation system mentioned by Gunnar allows for getting > translations into Ubuntu on a shorter timescale, and doing translation > work across the whole distribution in one place. It usually doesn't > result in translations being shared with other distributions. ... and if you're talking about other manual pages that you access using the "man" command, I don't think translations of those can in general be handled using Ubuntu's normal translation system. You'd need to work with individual upstream projects on that. -- Colin Watson [cjwat...@ubuntu.com] -- 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: PT-BR translation
On Sun, Apr 12, 2020 at 12:54:07PM -0400, Kinder wrote: > How do I contribute to the ubuntu PT-BR translation? preferably the command > "man"? Speaking as the upstream maintainer of man, the most long-term-effective way to do this is to work with the Translation Project and thus contribute the translations upstream (https://translationproject.org/html/welcome.html). This work will be shared with other distributions. The Ubuntu translation system mentioned by Gunnar allows for getting translations into Ubuntu on a shorter timescale, and doing translation work across the whole distribution in one place. It usually doesn't result in translations being shared with other distributions. -- Colin Watson [cjwat...@ubuntu.com] -- 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 Tue, Feb 25, 2020 at 03:48:14PM -0500, Mike Purvis wrote: > As far as launchpad engagement, it looks like this would be the page for > that, but the bugtracker isn't active on it: > https://launchpad.net/debian/+source/eigen3 No, if you're filing bugs on Ubuntu, you should use /ubuntu, not /debian, so https://launchpad.net/ubuntu/+source/eigen3. (https://launchpad.net/debian exists mainly as a convenience and as a by-product of the way we sync changes from Debian; it's not part of Debian's development workflow.) The simplest thing would be to run "ubuntu-bug eigen3". -- Colin Watson [cjwat...@ubuntu.com] -- 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 Tue, Feb 25, 2020 at 02:38:54PM -0600, Richard Laager wrote: > 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.) focal syncs from unstable, not testing. > So it'd need to be a patch that goes direct into Ubuntu. Not necessarily. After automatic syncs stop on Thursday, we can still sync uploads from Debian as long as they meet the criteria for feature freeze (which it sounds like this would, as long as it doesn't come with other changes); it just has to be something that an Ubuntu developer does manually rather than something that will happen without human intervention. -- Colin Watson [cjwat...@ubuntu.com] -- 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: Sugar desktop on Focal
On Sat, Feb 15, 2020 at 06:53:06AM +1100, James Cameron wrote: > Dimitri, I don't know enough about sponsorship to know if this is a > request for sponsorship, but previously Debian did package Sugar, and > in consequence Ubuntu made it available. That has changed, and I > don't know why, but I guess it is because people are too busy. You can always look at https://launchpad.net/ubuntu/+source//+publishinghistory to see what happened. For instance: https://launchpad.net/ubuntu/+source/sugar/+publishinghistory ... expand the "Deleted" row for focal at the top and you see the removal reason: "remove sugar, depending on pygtk" -- Colin Watson [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Memory Leak proftpd-basic Version 1.3.5e-1build1
On Sun, Dec 08, 2019 at 05:39:53PM +, Niklas Brückelmayer wrote: > I want to report a bug in proftpd-basic. Bug reports go in Launchpad, not here. However ... > I installed this software thru "apt install proftpd-basic" and got > verion 1.3.5e-1build1 > > In this version there is a memory leak because when I transfer huge > amounts of data (in my example approx. 500GB) all available RAM got > "cached" and Linux starts to use swap! Cached data in RAM is good (it means your system is keeping things in RAM when it might possibly save it from rereading them more slowly from disk), and using swap isn't necessarily bad. If your system can make better use of the available RAM than by using it to keep bits of running but rarely-used processes in memory, then it may decide to swap out parts of those processes, and this is fine. Swap *thrashing* (being so RAM-constrained that your system ends up spending too long swapping pages of memory back and forward between RAM and disk, at the cost of getting anything useful done) is bad. Merely using swap at all is not bad: it just indicates that your system is taking advantage of having a couple of different tiers of virtual memory with different performance characteristics, and is moving rarely-used things to the slower tier. In order to show evidence of a memory leak in proftpd, you would need to show that the proftpd process itself is growing. But that's not what memory that you see as "buff/cache" in top(1) or free(1) output is, and what you've described so far sounds like normal behaviour to me. -- Colin Watson [cjwat...@ubuntu.com] -- 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: selective sync from debian: haproxy case
I have no real opinion on the main question, but on a question of fact: On Mon, Dec 02, 2019 at 04:52:08PM -0300, Andreas Hasenack wrote: > On Mon, Dec 2, 2019 at 3:35 PM Steve Langasek > wrote: > > What about using a block-proposed bug on the package instead? > > Hm, let's see how that would work. > > I file a bug saying this package shouldn't be synced automatically > (for example), and add that tag. Then each time there is a debian > update, it will not migrate, and I will check if that update is one I > want to have. > If yes, I remove the tag, let it migrate, and add the tag back again. > If not, I leave it as is, or perhaps ask someone from the release team > to remove it from proposed? Won't it just be synced again then? You'd likely want it removed from -proposed in that case so that it's possible to upload new versions. It wouldn't be auto-synced unless a newer version is then uploaded to Debian unstable. It might be worth somebody investigating beefing up auto-sync to support "block-auto-sync" bugs on packages for this sort of situation. -- Colin Watson [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: ZFS feature flags
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? 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. -- Colin Watson [cjwat...@ubuntu.com] -- 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
Reconsidering Ubuntu bug-filing redirection
g the bug reporting guidelines displayed there), keeping it only on /ubuntu/+filebug. This would still serve the purpose of stemming the flow of low-value bug reports that don't specify a package name, while making it easier for people who at least have some idea which bit of software is going wrong. -- Colin Watson [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Question on apt-get update
On Wed, Sep 25, 2019 at 05:40:13PM -0700, Dan Kegel wrote: > On Wed, Sep 25, 2019 at 6:19 AM kavitha R wrote: > > Why do we store the package full description in a different file? > > Possibly because apt was written in 1998 and it seemed like a good > idea at the time? Separating out descriptions was in fact done later: it saves a fair chunk of disk space if you're using multiarch, in which you have (e.g.) both amd64 and i386 Packages files, but the descriptions are large and mostly shared between them. -- Colin Watson [cjwat...@ubuntu.com] -- 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: Staging changes for future SRU landings
On Thu, Aug 29, 2019 at 10:33:37AM +0200, Julian Andres Klode wrote: > On Thu, Aug 29, 2019 at 03:59:04AM +0100, Colin Watson wrote: > > On Wed, Aug 28, 2019 at 07:41:10PM +0200, Matthias Klose wrote: > > > afaiu block-proposed tags on bugs are not specific to any series, so you > > > are > > > blocking updates across all series. Not really desired. > > > > block-proposed is in fact specific to the current development series. > > block-proposed-$SERIES exists and should work here, though. > > block-proposed seems to work across all series. look at > > https://bugs.launchpad.net/ubuntu/+source/gpgme1.0/+bug/1813581 > > and > > https://people.canonical.com/~ubuntu-archive/pending-sru.html > > and you see the blocked icon for the bionic SRU, but the bug > has block-proposed set, not block-proposed-bionic. Sounds like there's a disagreement between proposed-migration and sru-report. -- Colin Watson[cjwat...@canonical.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Staging changes for future SRU landings
On Wed, Aug 28, 2019 at 07:41:10PM +0200, Matthias Klose wrote: > On 28.08.19 19:32, Robie Basak wrote: > > Any comments on this plan? If there are no objections, I'll update the > > wiki page documentation to match. > > afaiu block-proposed tags on bugs are not specific to any series, so you are > blocking updates across all series. Not really desired. block-proposed is in fact specific to the current development series. block-proposed-$SERIES exists and should work here, though. -- Colin Watson [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Dead acute + c still produces ć instead of the more widely used ç
On Mon, Aug 05, 2019 at 11:07:08AM +0200, Nilson Santos Figueiredo Jr. wrote: > I just got a new laptop and installed the newest LTS Ubuntu version. > To my surprise, Ubuntu still cannot produce ç properly out-of-the-box in > the regular way when using the "US international with dead keys" layout. I believe that this behaviour is defined by libx11 (https://gitlab.freedesktop.org/xorg/lib/libx11) and it isn't as simple as saying that it always produces ć: it's supposed to depend on your locale. A grep should make the intent clear: $ git grep '^ ' nls nls/en_US.UTF-8/Compose.pre: : "ć" U0107 # LATIN SMALL LETTER C WITH ACUTE nls/fi_FI.UTF-8/Compose.pre: : "ć" U0107 # LATIN SMALL LETTER C WITH ACUTE nls/iso8859-1/Compose.pre: : "\347" ccedilla nls/iso8859-13/Compose.pre: : "\343" cacute nls/iso8859-15/Compose.pre: : "\347" ccedilla nls/iso8859-2/Compose.pre: : "\346" cacute nls/pt_BR.UTF-8/Compose.pre: : "ç" ccedilla # LATIN SMALL LETTER C WITH CEDILLA nls/pt_PT.UTF-8/Compose.pre: : "ç" ccedilla # LATIN SMALL LETTER C WITH CEDILLA I hope this will help you narrow down where the problem is: either the compose definitions aren't taking effect, in which case you'd need to track down what's supposed to be applying them and isn't, or the compose definitions are wrong, in which case you would be best off taking this up with X11 upstream. (That said, while I don't use dead-key layouts myself, I seem to get ç when I type Compose ' c even though that isn't what the Compose file says I should get. Not quite sure what's going on there.) > "Ć" is a character that is used in Polish (38.5 million speakers) and > apparently also Croatian (6 millions speakers) and some related languages > when using loanwords. > "Ç" on the other hand, is used by Portuguese (215-260 million speakers), > French (80 million native, 270 million total speakers), Turkish (75 > million), Catalan (4-10million), Albanian (5 million), Azerbaijani (23 > million), plus at least Tatar, Turkmen, Kurdish and Zazaki, Friulian, > Ligurian and Occitan. Given that this is (as far as I can tell) supposed to depend on the locale, there should be no need to play off different groups of people against each other like this. -- Colin Watson [cjwat...@ubuntu.com] -- 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: dmeventd Changes Not Available
On Wed, Jul 24, 2019 at 10:58:53AM -0400, Matthew Rubenstein wrote: > Hello. In my Ubuntu 18.04.2 LTS host the system-update > application has been offering for several weeks to upgrade 4 dmeventd > packages: dmeventd , libdevmapper-event1.02.1 , libdevmapper1.02.1 , > dmsetup but the Technical description / Changes GUI says "The list of > changes is not available yet." Further, the URL offered in that GUI as > an alternate source of changes info leads to an invalid page: > > http://launchpad.net/ubuntu/+source/lvm2/2%3A1.02.145-4.1ubuntu3.18.04.1/+changelog This is https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/655917. I've fixed it in 19.04 and above, but the fix hasn't (yet?) been backported to 18.04. The bug is purely in update-manager, and doesn't have any bearing on the safety of the upgrade. -- Colin Watson [cjwat...@ubuntu.com] -- 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: grub2 package is still on version 2.02, although version 2.04 solves a big bug
On Sat, Jul 13, 2019 at 12:51:11PM +0200, Oskar Roesler wrote: > grub2 (and therefore, Ubuntu) can't be installed on some UEFIs because > of this bug: http://wiki.linuxfromscratch.org/lfs/ticket/4354 > > The bugfix > <http://git.savannah.gnu.org/cgit/grub.git/commit/util?id=842c390469e2c2e10b5aa36700324cd3bde25875> > is already there for over a half year, but even though this bug is that > big, you still have to build the fixed grub version manually. > > Debian has version 2.04 still in sid, but I would consider to jump to > 2.04 earlier, to make installing Ubuntu on those problematic UEFIs > possible for unexperienced users again. Upgrading stable releases to 2.04 is extremely unlikely, but the Ubuntu grub2 maintainers can and do cherry-pick individual fixes instead. I suggest filing a bug against the Ubuntu grub2 package to request that. -- Colin Watson [cjwat...@ubuntu.com] -- 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: I would like to contribute to debianutils
On Thu, Jul 04, 2019 at 06:48:27PM +0200, Erik Gustafsson wrote: > The "which" command is part of debianutils. On BSD and Mac, this > command on Mac/BSD has a -s flag, which is basically, silent, and > return 0 if program found in $PATH or 1 otherwise I've only ever seen the convention of redirecting output to /dev/null, which I would assume could also be done in a way that's compatible between Debian and the BSDs. An -s option seems like a reasonable enough thing to have, though. > The current version of "which" supplied with Debian is written in shellscript > https://salsa.debian.org/debian/debianutils/blob/master/which Yes, it's descended from a version I wrote many years ago. :-) (I haven't been responsible for maintaining it for a long time, though.) > To make my Debian installation compatible with "which -s" in > shellscripts I would like to contribute the -s flag to debianutils. I > have already made a working implementation, which I am happy to > improve on as needed. (attach with this email) As general advice, almost nobody will ever want to review something sent in the form of "here is a complete new version of the code". The baseline standard in free software development is to send patches instead that express the difference between the current and proposed versions, which were traditionally produced using "diff -u" but nowadays are more usually produced by something like "git format-patch". (In many cases, of course, this is all wrapped up in something like a "pull request" or "merge request" or whatever individual sites call it, where you push git commits to a branch somewhere and then fill in some kind of form which asks the maintainer to merge stuff from your branch. It's still useful to be familiar with working with patches, since that's still what the maintainer will be looking at when deciding whether or not to merge your changes.) > How can I get started to contribute to debianutils? Should I have an account > on > https://salsa.debian.org/debian/debianutils ? It would probably be best to create a Salsa account, fork that repository, commit your changes, and send a merge request, yes. You could also send a patch as a Debian bug report against debianutils, which is done by sending an email in the right format to a special address (see https://www.debian.org/Bugs/Reporting). > Can someone else contribute this code for me, once I get it to reach a > good quality level of code and documentation? It's really best if you can make the contribution directly yourself. Going through somebody else is possible but it's more cumbersome, since it means that if the maintainer has any questions then they have to be relayed through somebody else too. > I found this email address by typing > apt-cache show debianutils , in the Maintainer field Ubuntu overrides the Maintainer address of most packages to this list to avoid being responsible for too much noise sent to Debian maintainers for packages that they didn't prepare. However, in this case our version of debianutils is an unmodified copy of the one in Debian, and it would be very much better for this sort of change not to be specific to Ubuntu, so for this sort of thing you should work directly with the Debian maintainer. Thanks, -- Colin Watson [cjwat...@ubuntu.com] -- 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: RFC: baseline requirements for Ubuntu rootfs: xattrs and fscaps
On Wed, Jun 12, 2019 at 11:40:57AM -0700, Brian Murray wrote: > For the record, I've found out[1] this is actually an upstream bug in > the documentation for which I have submitted some patches to clarify the > behavior of --xattrs-include. > > [1] https://lists.gnu.org/archive/html/bug-tar/2019-06/msg2.html Thanks for chasing this up! -- Colin Watson [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Proposal: drop rails and its reverse-dependencies from Ubuntu 19.04 [Re: Maintaining language-specific module package stacks]
On Thu, Apr 04, 2019 at 02:07:50PM +0200, Matthias Klose wrote: > This is short-sighted, and greatly influenced by the voices of > language-specific > upstream communities. As seen at several occasions at PyCon: Ask an upstream > community, which Linux distribution they use (majority of hands go up for > Ubuntu), and then how many of those use the system Python (majority of hands > go > down). Please ask this Python question to an upstream Java, upstream Ruby > community, and I assume that nobody cares and uses the Python as distributed > by > Ubuntu. Ask the Java and Python communities the same question about Ruby, and > these are probably happy with the Ruby found on Ubuntu. Now remove the Ruby, > Python and Java stacks, and probably nobody will be happy anymore. I agree strongly with this, and I think it's well-put. When I'm working on (say) Launchpad, I'm acting as a Python developer, and I'm much more likely to look to PyPI for dependencies than to look to the Ubuntu archive. On the other hand, when I'm installing (say) icingaweb2 to help me monitor systems on my local network, I'm *not* acting as a PHP developer despite the fact that it happens to be implemented in PHP; I just want to install something vaguely sensible and maintained and have it work, rather than having to teach myself how PHP repositories work, and having my distribution suddenly tell me that I have to do the latter would be a considerable inconvenience. In the case of Rails, perhaps most users of that package would be Ruby developers anyway and thus would be perfectly happy to use Ruby-specific repositories, although I don't know that for sure and you'd need to ask people who actually use it. However, we should be very wary of generalising from this case to cases of packages that can be used with only minimal experience with their implementation language. I would say that removing poorly-maintained packages that are mainly used by people in developer roles is very different from removing poorly-maintained packages that are mainly used by people in user roles. (I've chosen my words carefully here to emphasise that the same people may very well have different roles depending on what they're doing.) -- Colin Watson [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: going ahead of Debian with a dfsg orig tarball
On Tue, Mar 19, 2019 at 02:19:00PM -0300, Andreas Hasenack wrote: > I find myself in the situation where we want to go ahead of debian for > a package (samba), but it's a dfsg tarball. Debian doesn't have it > anywhere yet, so I produced the tarball according to the exclude rules > in debian/gbp.conf. > > I'm wondering, however, if some mistake happens, or something else, > and the tarball I produce has a different hash than the tarball that > Debian will eventually produce. Since my upload will be in Ubuntu > already, what will happen when Launchpad will try to ingest Debian's > upload, and finds out the orig tarball has a different md5, but the > same name as the Ubuntu one? If that happens, then it won't be possible to sync the Debian package, and you'll have to use "syncpackage -F" to work around that (assuming there are no other Ubuntu changes; if there are, then you can just merge manually instead). > To avoid that, I previously mangled the name of our orig tarball to > use ...+dfsg~ubuntu-0ubuntu1 (i.e., I added the ~ubuntu bit after > +dfsg), but that looks ugly. I suppose that works well enough. It wouldn't be the first package version to have multiple "ubuntu" substrings. > Is there some recommended way of handling this, or am I just planning > too much for something that won't be an issue? I'd recommend talking to your Debian counterpart(s) to see if it's possible to agree in advance on a particular orig tarball representation of this upstream release. -- Colin Watson [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: arch triplet: "-" <> "_"
On Thu, Feb 28, 2019 at 03:11:35PM -0800, Steve Langasek wrote:
> On Wed, Feb 27, 2019 at 02:08:29PM -0300, Andreas Hasenack wrote:
> > So I thought about using dh-exec, just like
> > https://wiki.debian.org/Multiarch/Implementation#Dynamic_debian.2F.2A_files
> > suggests, but that didn't work.
>
> > The silly problem is that the triplet x86_64-linux-gnu as a directory
> > is not the same triplet used in the filename: x86_64-linux-gnu !=
> > x86-64-linux-gnu ("-" vs "_")
>
> > Is there a neat solution to this, other than using "*" for the architecture?
>
> No, since x86-64-linux-gnu is not a standard name for the architecture. I
> would suggest that you instead simply use the dh-exec substitution for the
> first part of the path, and a glob for the second:
>
> usr/lib/${DEB_HOST_MULTIARCH}/libpytalloc-util.cpython-37m-*.so.*
>
> That should minimize any false-positive matches of the glob.
This seems OK. If you wanted to be more precise, then you could
calculate the appropriate respelling of the architecture name in
debian/rules, stash it in an environment variable, and substitute that
using dh-exec (see dh-exec-subst(1)). But it's probably not worth it.
--
Colin Watson[cjwat...@canonical.com]
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: authbind in platform/supported-sysadmin-common
On Tue, Feb 12, 2019 at 10:10:08AM -0200, Andreas Hasenack wrote: > while investigating removing authbind from the server-ship seed[1], we > noticed it's still included via platform/supported-sysadmin-common. I > tracked this back to 2008 when the file was created already with that > content, so no particular reasoning was logged in the commit. FWIW, Launchpad still uses authbind on production as part of its init scripts for some of its custom SSH-based services. -- Colin Watson [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: anyone still use 'import-bug-from-debian'?
On Wed, Feb 13, 2019 at 08:40:39AM -0500, Dan Streetman wrote: > As far as I can tell, this hasn't been used by anyone in a long time, > or at least only a small number of times. > > Can anyone who uses it let me know? If it's helpful, there are 409 bugs in Launchpad whose description starts with the string "Imported from Debian bug"; the most recent one (https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1694425) was created on 2017-05-30. It was quite heavily used up to 2015 or so; my general impression is that it's a slightly obscure tool so not widely used, but probably used enough to justify keeping it around. -- Colin Watson [cjwat...@ubuntu.com] -- 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: help with sbuild dep8 failures on i386/bionic
On Fri, Nov 30, 2018 at 05:04:35PM -0200, Andreas Hasenack wrote: > The test basically uses sbuild to build procenv on the current devel > version of ubuntu. Today, that's disco. At the end of the build, it > tries to install the built package on the host, and this is the first > red flag. I guess this should either build on the host series, or else it should create a new temporary schroot and install the built package in that for testing. > That is why it's failing on i386: > The following packages have unmet dependencies: > procenv : Depends: libc6 (>= 2.28) but 2.27-3ubuntu1 is to be installed > E: Unable to correct problems, you have held broken packages. > > bionic has libc6 2.27, disco has libc6 2.28. So the above error makes sense. > > But in the amd64 build, this does not happen. The built package has > this Depends line: > Depends: libc6 (>= 2.17), libcap2 (>= 1:2.10), libnuma1 (>= 2.0.11), > libselinux1 (>= 1.32) > > > How?? Going up in the dep8 logs even shows that it used libc6-dev-2.28 > in the sbuild :) The libc6 dependency that a binary package gains when built isn't necessarily the same as the libc6-dev version that was installed when it was built. The major point of symbols files is to allow library dependencies to be weaker when the binary doesn't actually need a newer version of the library, checking on a symbol-by-symbol basis. Presumably some quirk of the architecture-specific code for i386 in libc means that procenv ends up needing 2.28 on that architecture; for instance, this might happen if the implementation of a syscall wrapper changed on i386 in such a way as to cause binaries built using 2.28 headers to require a newer libc at runtime. This sort of thing is in fact not all that uncommon, particularly given the large amount of architecture-specific code in libc. You could probably narrow down exactly what symbols are involved by doing "objdump -wT" on the built i386 procenv binary and looking for GLIBC_2.28 symbols, although it probably isn't necessary to track that down since it's clear that the test is buggy: building a package on a newer series and trying to install it on an older one isn't something that can be guaranteed even if it often works. -- Colin Watson [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Requiring Launchpad 2FA from Ubuntu uploaders
On Tue, Aug 14, 2018 at 01:35:00PM -0500, Simon Quigley wrote: > On 08/14/2018 11:34 AM, Colin Watson wrote: > > How would this work, even conceptually? Some kind of extra challenge > > when doing SFTP uploads or git/bzr pushes to ask for 2FA (and some > > timeout arrangement so that it isn't hopelessly annoying)? What about > > FTP uploads? > > In my opinion, SFTP should be the default for uploads to Ubuntu*, and we > should phase out FTP. My local /etc/dput.cf has been patched to do this > for a while now, and it works fine. The reason we haven't done this is that there's no good way to make it the default in everyone's dput configuration. > If this is done, we should be able to use PAM with google-authenticator. Not an option; Launchpad's SSH endpoints are custom servers, not OpenSSH, and don't use PAM. -- Colin Watson [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Requiring Launchpad 2FA from Ubuntu uploaders
On Tue, Aug 14, 2018 at 05:18:38PM +0200, Philipp Kern wrote: > - u2f support. I agree that would be useful (https://bugs.launchpad.net/canonical-identity-provider/+bug/1755021). Maybe somebody with skills in this area could look into lp:canonical-identity-provider and see what's involved in adding it? > Getting out the HOTP token (I guess I enrolled too early for TOTP) is > annoying. If I'm understanding you right, you can easily just add a TOTP device to your SSO account. > But I guess a Launchpad session is pretty permanent, so you don't > actually need to reauth on the same device, right? (Which might also > be a bad thing.) I didn't think they were quite permanent, but that bit of LP is very stable code and I've never had to dig into it to find out. There are certain operations that require a fresh SSO login (editing SSH keys, GPG keys, or email addresses). > - It only protects access to Launchpad, not access to the keys that sign the > uploads and ultimately control what gets put into the archive. Shouldn't > there be a way behind 2fa to contribute to Ubuntu as well? :) How would this work, even conceptually? Some kind of extra challenge when doing SFTP uploads or git/bzr pushes to ask for 2FA (and some timeout arrangement so that it isn't hopelessly annoying)? What about FTP uploads? -- Colin Watson [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Requiring Launchpad 2FA from Ubuntu uploaders
On Tue, Aug 14, 2018 at 02:31:05PM +0100, Robie Basak wrote: > Launchpad 2FA is currently opt-in for everyone. However, it has been > mandatory for Canonical employees for a number of years now. Details are > documented here: > > https://help.ubuntu.com/community/SSO/FAQs/2FA > > TOTP and HOTP are supported, so this works with hardware authenticators > such as Yubikeys as well as smartphone apps like OTP Authenticator (from > F-Droid) and Google Authenticator (Play Store), etc. > > We[1] think this is now easy enough and standard enough not to be a > burden, so we are inclined to implement this as a requirement for all > Ubuntu uploaders[2]. Any objections? This isn't a hard objection, but one thing to consider is that we don't have a terribly good recovery mechanism at the moment; indeed, this is why 2FA in SSO still has a slightly complicated and explicit opt-in procedure for most people. For Canonical employees, we avoid this being a fatal problem because we have ways to do out-of-band verification when (not if) people lose their 2FA tokens, since if nothing else their manager should be in regular contact with them. Is that something we can expect to have for all Ubuntu uploaders? I suppose we could manually exchange GPG-signed email with them or something ... -- Colin Watson [cjwat...@ubuntu.com] -- 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 Wed, Aug 01, 2018 at 05:58:56PM -0700, Steve Langasek wrote: > This will require bugfixes in various places, but ideally on a one-time > basis only. The primary areas of concern are: I think launchpad-buildd needs a couple of fixes for this, but there are some things to fix that aren't quite one-liners. Firstly, we need to pass --xattrs-include=* when unpacking chroots. That much is straightforward. Secondly, the machinery that creates Launchpad build chroots needs to pass --xattrs. That machinery is currently Adam Conrad's shell history, but we're in the process of moving it into livecd-rootfs, and that will need a minor adjustment. The third problem is the one that isn't trivial. Some Launchpad builds are run in LXD containers rather than in chroots, and in those cases we first mangle the chroot tarball into a shape that can be imported by LXD. We currently do this using Python 2.7's tarfile module, but as far as I can see that doesn't quite support xattrs properly due to encoding issues. I can think of a couple of options: * We could take some approach like https://github.com/docker/docker-registry/pull/381/files to monkey-patch tarfile, or we could finish the upgrade of launchpad-buildd to Python 3 (which is within reach). In either case, we'd need to work out how to invoke tarfile correctly to preserve xattrs; I think that's probably a fairly small change, but it'll require some investigation and testing. * Once we've completed the move of chroot creation into livecd-rootfs, it may be practical to have that produce LXD containers too, and in that case we could drop the Python-based mangling. In the long term this would be preferable because it would save a minute or two at the start of many builds. None of this is super-urgent since I don't think there's anything in the chroots that requires xattrs, but we should remember to fix it to avoid future surprises. -- Colin Watson [cjwat...@ubuntu.com] -- 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 Wed, Aug 01, 2018 at 05:58:56PM -0700, Steve Langasek wrote: > - Users who are unpacking root tarballs need to take care to pass >--xattrs-include=* to tar. The tar documentation suggests that just --xattrs should be enough: By default, when '--xattr' is used, all names are stored in the archive (or extracted, if using '--extract'). Am I missing something? -- Colin Watson [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: dpkg-query --load-avail not working?
On Sun, May 27, 2018 at 03:42:26PM -0400, Tong Sun wrote: > If so, then somehow dpkg-query --load-avail is not working: > > $ dpkg-query --load-avail --list 'golang-github-*' > dpkg-query: no packages found matching golang-github-* It'll work if /var/lib/dpkg/available is being kept up to date, which apt doesn't do by default. You can use "dselect update" in place of "apt update" to update the available file as well as doing the other index-update tasks. -- Colin Watson [cjwat...@ubuntu.com] -- 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: Proposal: Let's drop i386
On Sun, May 13, 2018 at 08:42:49PM +0200, Ole Streicher wrote: > Henri Sivonen <hsivo...@hsivonen.fi> writes: > > If 32-bit x86 support becomes mainly a thing that's run on x86_64 > > hardware as a compatibility measure for things like Wine, it would > > make sense to bring the instruction set baseline to the x86_64 level. > > Specifically, it would make sense to compile the 32-bit x86 packages > > with SSE2 unconditionally enabled. > > There is already an x32 ABI port in Debian (and I thought it also was in > Ubuntu at some time?) x32 has never been in Ubuntu. But in any case x32 is an entirely different ABI, which is unrelated to the ISA baseline selected for i386. -- Colin Watson [cjwat...@ubuntu.com] -- 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: Proposal: Let's drop i386
On Sun, May 13, 2018 at 02:33:08PM -0400, Jeremy Bicha wrote: > On Sun, May 13, 2018 at 1:57 PM, Colin Watson <cjwat...@ubuntu.com> wrote: > > IIRC Steam is also relevant, and I guess that would involve talking to > > Valve? > > I think our users would be better served by Steam becoming a Snap. I > have more explanation at https://launchpad.net/bugs/1759715 > > I suppose that could be done for Wine too although Wine doesn't > currently have the unsolved maintenance challenges that Steam does. Would this involve building with -m32 rather than shipping copies of i386 packages from the archive? (If the former, I agree that that would help with this class of problem. If the latter, it would at best defer the problem for a few years.) -- Colin Watson [cjwat...@ubuntu.com] -- 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: Proposal: Let's drop i386
On Sun, May 13, 2018 at 02:33:08PM -0400, Jeremy Bicha wrote: > On Sun, May 13, 2018 at 1:57 PM, Colin Watson <cjwat...@ubuntu.com> wrote: > > IIRC Steam is also relevant, and I guess that would involve talking to > > Valve? > > I think our users would be better served by Steam becoming a Snap. I > have more explanation at https://launchpad.net/bugs/1759715 > > I suppose that could be done for Wine too although Wine doesn't > currently have the unsolved maintenance challenges that Steam does. Would this involve building with -m32 rather than shipping copies of i386 packages from the archive? (If the former, I agree that that would help with this class of problem. If the latter, it would at best defer the problem for a few years.) -- Colin Watson [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Proposal: Let's drop i386
On Thu, May 10, 2018 at 04:25:25PM -0400, Thomas Ward wrote: > However, killing i386 support globally could introduce issues, including > but not limited to certain upstream softwares having to go away > entirely, due to the interdependency or issues with how certain apps > work (read; Wine, 32-bit support, 64-bit support being flaky, and > Windows apps being general pains in that they work on 32bit but not > always on 64-bit). Is there any possibility of building this kind of thing in biarch style (i.e. on the amd64 architecture, but with -m32 or similar)? I know that may well involve building some more biarch libraries along the way, but it would give us an exit strategy that doesn't involve dropping things like Wine. IIRC Steam is also relevant, and I guess that would involve talking to Valve? -- Colin Watson [cjwat...@ubuntu.com] -- 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: Proposal: Let's drop i386
On Thu, May 10, 2018 at 04:25:25PM -0400, Thomas Ward wrote: > However, killing i386 support globally could introduce issues, including > but not limited to certain upstream softwares having to go away > entirely, due to the interdependency or issues with how certain apps > work (read; Wine, 32-bit support, 64-bit support being flaky, and > Windows apps being general pains in that they work on 32bit but not > always on 64-bit). Is there any possibility of building this kind of thing in biarch style (i.e. on the amd64 architecture, but with -m32 or similar)? I know that may well involve building some more biarch libraries along the way, but it would give us an exit strategy that doesn't involve dropping things like Wine. IIRC Steam is also relevant, and I guess that would involve talking to Valve? -- Colin Watson [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Ubuntu packaging: package libxcomposite-dev
On Fri, May 04, 2018 at 09:11:14PM +0300, Lapshin Dmitry wrote: > I have found out that libxcomposite-dev in Bionic depends on > transitional package x11proto-composite-dev (that depends on > x11proto-dev solely). Should the dependency be fixed? Possibly; but this is true in Debian unstable as well, so it would be best to report it there first and then it can trickle down. (A minor problem like this wouldn't meet the criteria for stable updates, but it could be fixed for later releases.) Thanks, -- Colin Watson [cjwat...@ubuntu.com] -- 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: extlinux dependent issue
On Sat, Apr 28, 2018 at 05:55:44PM +0200, Ralf Mardorf wrote:
> I'm surprised that "syslinux{,-common}" are in "main", see
> https://packages.ubuntu.com/bionic/syslinux{,-common} and "extlinux" is
> in "universe", see https://packages.ubuntu.com/bionic/extlinux, while
> all belongs to the same upstream source.
This is routine when only some of the binaries are actually used for
main-like purposes. (syslinux is used for Ubuntu ISO images when
booting in BIOS mode.)
--
Colin Watson [cjwat...@ubuntu.com]
--
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: zstd compression for packages
On Mon, Mar 12, 2018 at 03:36:11PM +0100, Julian Andres Klode wrote: > Acknowledged. I don't think we want to go ahead without dpkg upstream > blessing anyway. On the APT side, we don't maintain Ubuntu-only branches, > so if we get a go-ahead it would land in Debian immediately too. Good. > I had a quick look at Launchpad and I think it only needs a backport of > the APT commits to an older branch (or an upgrade to bionic, but that > sounds like more work :D) but I might be wrong. We'll probably also need a dpkg backport (preferably in xenial-updates) and some small changes to lib/lp/archiveuploader/. It's not hugely difficult but will need a bit of work. -- Colin Watson [cjwat...@ubuntu.com] -- 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:02:49AM -0400, Jeremy Bicha wrote: > On Mon, Mar 12, 2018 at 6:06 AM, Julian Andres Klode > <julian.kl...@canonical.com> wrote: > > We are considering requesting a FFe for that - the features are not > > invasive, and it allows us to turn it on by default in 18.10. > > What does Debian's dpkg maintainer think? FWIW, I'd be quite reluctant to add support for this to Launchpad until it's landed in Debian dpkg/apt; a future incompatibility would be very painful to deal with. -- Colin Watson [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Ubuntu-devel-discuss Digest, Vol 135, Issue 11
On Sun, Feb 11, 2018 at 09:56:18AM -0500, Technical Clarity wrote: > Sorry, Canonical has UbuntuOne accounts, can Ubiquity pare with UbuntuOne > and through its UbuntuOne and it's derivatives should have access, how much > can we extend in UbuntuOne features The remaining piece of Ubuntu One is login.ubuntu.com, providing account management and single sign-on to a number of sites. It has basically no bearing on cross-distribution installation/upgrade. -- Colin Watson [cjwat...@ubuntu.com] -- 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: RFC: Ubuntu Seeded Snaps
On Fri, Feb 09, 2018 at 11:20:53AM +0100, Oliver Grawert wrote: > Am Freitag, den 09.02.2018, 09:37 + schrieb Robie Basak: > > Should this be a side effect subject to change of store policy > > (which I think is outside the scope of the Ubuntu project?), or > > should we define "no devmode" as an Ubuntu policy now? > > this is an already existing store policy ... if your snap was built > with "confinement: devmode" you can not release it to stable, the store > checks this and blocks. so the "only stable" policy on the ubuntu side > should be enough. Regardless of the question of governance of that policy, there's also the fact that the spec calls for following a per-series channel, for which I don't think a "no devmode" store policy is currently configured. -- Colin Watson [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: RFC: Ubuntu Seeded Snaps
On Fri, Feb 09, 2018 at 09:37:17AM +, Robie Basak wrote: > On Thu, Feb 08, 2018 at 03:10:08PM -0800, Steve Langasek wrote: > > Snaps included in images will be installed referencing a per-Ubuntu-series > > branch. This ensures forwards-compatibility by allowing publishing to this > > branch if the mainline of a snap becomes incompatible with a given Ubuntu > > release, without requiring up-front maintenance of multiple snap channels. > > I don't follow this. Are you suggesting that the seed list a snap > version number? Or a specific code branch in Launchpad from which the > snap ending up in the images will get built? If the former, wouldn't the > install base become "stuck"? Store channel names are formed as [track/]risk[/branch]; it's this kind of branch that Steve is referring to. (The spec should probably just say "channel", though.) I'm not sure how this can avoid requiring up-front maintenance of multiple snap channels. If the proposal is that we install snaps in a way that will cause refreshes to pull from a pre-configured per-series channel, then unless that channel actually exists then "snap refresh" is surely going to be returning errors, which doesn't seem like a good stock configuration. This raises another point; when upgrading to versions beyond 18.04, users' systems will need to be modified to follow the appropriate per-series channel for each of these preinstalled snaps. Somebody will need to teach the upgrader to do this, and it will also need to be documented for people who don't use update-manager/do-release-upgrade. > I'm very much in favour of the above two requirements, but there's also > a little more. With the current archive, these are some existing > properties that I think should be considered for inclusion in this > policy. > > * _Users_ (rather than just developers) can retrieve the full source >associated with a package from Launchpad with no other external >dependencies and rebuild it themselves, and tooling exists for this. > > * Users can find the build logs associated with every binary shipped >from the archive. > > * The above two statements are true both for packages that a user is >considering installing but has not yet installed, and for packages >that a user has installed locally. > > Does any of this exist with snaps today (that were built from source on > Launchpad)? I haven't been able to find any suitable connection to > identify the provenance of a snap in this way. If they were built on Launchpad with the proposed changes to disallow external network access, then all the necessary information exists, but there's currently no tooling to help users actually find it. -- Colin Watson [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: debmirror compatibility with Kali
On Tue, Jan 16, 2018 at 06:54:38PM -0500, Derek Murphy wrote: > I'm having a few issues with debmirror working with the Kali repo. We are > using this for offline networks at work and I have ubuntu and debian both > working stably. My issue is with the size error messages. > > Please let me know what you think. > > user@nodata-gaming:/mnt/d/Linux_Repo# ./mirrorbuild_kali.sh I don't think this is something I've fixed in later versions, but I'd need to dig. Could you please file a Debian bug against debmirror (https://www.debian.org/Bugs/Reporting) containing: * the version of debmirror you have installed * the full contents of the debmirror wrapper script you're running (editing out any secrets if necessary, but there probably aren't any) -- Colin Watson [cjwat...@debian.org] -- 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: firefox 57.x extention "Ubuntu Modifications" no longer compattible...
On Mon, Jan 01, 2018 at 08:57:25PM -0700, Verwijs1969 wrote: > firefox 57.x extention "Ubuntu Modifications" no longer compatible... please > update or remove.. It was made an empty package a couple of months ago, but this apparently wasn't copied forward to bionic. I've done that now. -- Colin Watson [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: On Lists and Iterables
On Sun, Dec 17, 2017 at 12:22:20PM +0100, Xen wrote: > Neal McBurnett schreef op 16-12-2017 18:16: > > For more on the rationale for changes related to iterators see > > http://portingguide.readthedocs.io/en/latest/iterators.html > > That entire rationale is only explained with one word "memory consumption". > > So now you are changing the design of your _grammar_ just so that the > resulting code will use less memory. > > That is the job of the compiler, not the developer. I don't think the document above does a particularly good job of explaining it, and I think you've fundamentally misunderstood things, perhaps by extrapolating too much from toy examples. zip() takes iterables as its inputs; concrete lists are only one kind of iterable. Iteration constructs are very widespread in non-trivial Python code, and it's common to make use of iterators to express constructions where you can cheaply extract a few elements but it would be expensive to extract them all. For example, I spend most of my time working on database-backed web applications, which is a very popular application for Python. In that context, it's commonplace to make database queries via functions that return iterators and do lazy loading of results. You then iterate over these to build a page of results (which can use things like LIMIT and OFFSET when compiling its SQL queries), and you render and return that. If you accidentally call something that consumes the whole input iterable in the process, then it's going to do a *lot* of database traffic for some queries, and it doesn't take much of that to utterly destroy the performance of your application. This is not something that the compiler can optimise, because the *contract* of zip et al in Python 2 was that it would consume the entire inputs (up to the shortest one in the case of zip, anyway); iteration is visible to the program and can have external side-effects, and it's not something that can be quietly optimised out given the design of the language. Talking about memory consumption of the result is relevant in some cases, sure, but it's certainly not the whole story; what often matters is the work involved in materialising the whole iterable, and that can be very significant indeed. In Python 2, there were many functions that took iterables as input and returned concrete lists, consuming the entire inputs in the process. In most cases there were versions of these that operated in a lazy fashion and returned iterables instead, but they were generally hidden off in the itertools module and less obvious compared to the built-in versions. Effectively, the language did the wrong thing by default. Python 3 changes these around to give preference to the versions that take iterables as input and return iterables as output, and says that if you want a list then you have to use list() or similar to get one. This reduces the cognitive load of the language, because now instead of remembering the different names for the list-returning and iterable-returning versions of various things, you only have to remember one version and the general rule that you use list() to materialise a whole iterable into a list (which was already useful for other things even in Python 2). It makes the language simpler to learn, because there are fewer rules and they compose well; and it makes it easier to do what's usually the right thing. This comes at the cost of a bit of porting effort for some code that started out in Python 2, of which there'll be less and less as time goes on. To put it another way: "don't perform operations on collections of unbounded size" is pretty much the number one rule for webapps that I've picked up over the last few years, and Python 3 takes this lesson and applies it to the core language. Toy examples involving zip([1, 2], [3, 4]) and the like miss the point because they simplify too much. This family of functions is almost always used in iteration constructs, usually "for ... in" or a comprehension, and in those common cases the programmer doesn't have to change anything at all. In cases where they do need to change something, it has the useful effect of highlighting that something a little unusual may be going on, rather than hiding behaviour that's potentially catastrophic at scale behind an innocuous-looking built-in function. > Meanwhile Python 3.4 can be excessively slower than 2.7. SO WHERE'S THE > GAIN? It will no doubt depend on the benchmark, and rather than cherry-picking a single one it's likely more interesting to look at either a wide range of benchmarks, or at the specific application in question. Counterpoint, which also links to much more data: https://lwn.net/Articles/725114/ -- Colin Watson [cjwat...@ubuntu.com] -- 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: On Lists and Iterables
on in saying that he would have > preferred a 'legacy' mode for the interpreter. I've explained already why I don't think it's particularly forced, and I'd also add that I do recognise that such a "legacy" mode would have been extremely difficult to build - retaining the ability to execute Python 2 code is one thing, but in practice you'd need to be able to pass data between the two worlds and to say the least it's not at all obvious how that could work (Perl 5 vs. 6 doesn't have this problem). Anyway, it's the nature of things that older versions of software are rarely maintained in perpetuity, so I find it pretty hard to get worked up about it. (Incidentally, I find it pretty weird when anyone who isn't, say, my bank manager or something refers to me using a title. You don't seem to do that for other people in general, so I assume you're trying to make some kind of point, but I'm afraid it escapes me.) -- Colin Watson [cjwat...@ubuntu.com] -- 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: Python2 demotion (moving from main to universe) in progress
On Fri, Dec 15, 2017 at 03:38:20AM +0100, Xen wrote:
> Colin Watson schreef op 09-12-2017 13:51:
> > Even as somebody generally very sympathetic to the needs of
> > localisation, I've got this wrong because Python 2 had just too many
> > ways to make mistakes in this area.
>
> So you are basically saying that you still don't agree but you have somehow
> accepted your own fallibility in that something you like is wrong and
> something you dislike is right.
No - you're putting words in my mouth that are the opposite of what I'm
saying. Kindly don't reply to try to convince me otherwise.
In general, I dislike programming idioms that are too easy to get wrong.
> I happen to know the % operator ;-).
>
> It is ridiculous that you cannot use it for binary-only text, or what I
> would call just byte strings.
You can use the % operator on bytes, as of Python 3.5. Please spend
more time checking the assertions you make. It's the much newer
"format" method that still isn't supported on bytes, and from
https://bugs.python.org/issue3982#msg268160 it sounds like that's
intentional and well-founded.
https://docs.python.org/3/whatsnew/3.5.html#whatsnew-pep-461
(Python 3.5 is in Ubuntu 16.04; while some people may care, I'm not
personally especially interested in earlier versions of Python 3 at this
point, although I've been using it on and off since 3.2 or so.)
While I know there are exceptions, some mentioned in that issue link
above, on the whole my impression is that old Python code isn't likely
to be using str.format very much anyway, since it's a relatively modern
innovation compared to Python 2; it was introduced in 2.6.
> This example really says it all:
>
> Python 2: b'Content-length: {}\r\n'.format(length)
>
> Python 3: b''.join([b'Content-length: ', (bytes if bytes is str else
> str)(length).encode('ascii'), b'\r\n'])
>
> Or well, that is 2<>3 compatible code.
Sure, if you work at it you can always construct unnecessarily
complicated examples. "bytes if bytes is str else str" is strictly
identical to "str", on both Python 2 and 3. (Glyph is an extremely
experienced and competent developer, so I'm sure this was just an
oversight.)
But you can just do this instead, which in fact is roughly what Twisted,
the source of the above comment, now does:
Python 2/3: b'Content-Length: %d\r\n' % length
(As mentioned above, str.format was new in Python 2.6, so this is just a
return to the status quo ante for bytes.)
> So if this person does keep maintaining this project and it gets some
> traction, you could have a 'supported' python 2 interpretor being callable
> by "python2" or "python2.7" or even "python2.8" for some time to come.
>
> If more people rally around that you could even have an unofficial
> 'official' Python 2.8 specification ;-).
>
> Of which Tauthon would then be one interpreter ;-).
>
> You could then move Tauthon (package "tauthon") to universe around the time
> that you would move python 2.7 out of it.
If it turns out that the maintainer of Tauthon builds a sustained track
record of doing a good job with it, then I'd support it being available
in Ubuntu. There's still quite a while until Python 2.7 is in any
danger of being removed from Ubuntu, so there's time for them to develop
such a track record.
(I don't think we should hold back other packaged libraries to support
it, though; for example, Django 2.0 dropped support for Python 2. So it
might be that Tauthon users would end up in practice with an
Ubuntu-packaged interpreter and then using packages from PyPI in a
virtualenv for most things that aren't in the standard library, or
something like that. That would possibly work well enough; the audience
for something like Tauthon probably also wants to stick with old library
versions as well, at least until they can upgrade in a
tightly-controlled fashion.)
--
Colin Watson [cjwat...@ubuntu.com]
--
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: Cannot find required packages
On Wed, Dec 13, 2017 at 04:55:05PM +, Edmond Condillac wrote: > I'm trying to get started as an editor for the Ubuntu Manual Project > on the version 18.04 LTS (Bionic beaver). During installation of the > upstream version of TeX Live to compile the manual successfully, the > terminal command ~/Projects/ubuntu-manual-bionic/pkgs/install-pkgs.sh > gives the error output as follows: > > Require package list is: > > ttf-arabeyes > > ttf-kacst > > Kindly advise, if possible, how I may obtain these required missing packages, > please. Nowadays these are fonts-arabeyes and fonts-kacst respectively. The script in question should be updated to refer to the new names (which have existed for some years, so it should be an easy change to make). -- Colin Watson [cjwat...@ubuntu.com] -- 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: Road to new openssl
On Tue, Dec 12, 2017 at 03:59:50PM +, Dimitri John Ledkov wrote: > - openssh is being worked on and is complex, I am hoping for this > solution to work out > https://github.com/openssh/openssh-portable/pull/48 Upstream is not happy with this, and it's unlikely to be quite what we end up with. The threads starting at these points (they got a bit split up in the archives) are more up to date: https://lists.mindrot.org/pipermail/openssh-unix-dev/2017-October/036344.html https://lists.mindrot.org/pipermail/openssh-unix-dev/2017-October/036376.html https://lists.mindrot.org/pipermail/openssh-unix-dev/2017-November/036467.html At this point I cannot say with any particular confidence whether OpenSSH will be ready for this transition by 18.04, although it can cope with the current situation in Debian unstable where the default is 1.1 but 1.0 is also available. -- Colin Watson [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Python2 demotion (moving from main to universe) in progress
On Sat, Dec 09, 2017 at 12:47:28PM +0100, Xen wrote: > Colin Watson schreef op 09-12-2017 0:24: > > there are good reasons behind many of the changes in Python 3 > > You know, an appeal to "good reasons" is really a blanket statement that > betrays the absence of any good reasons. No, it betrays limited time to write. To take just one example, Python 2's willingness to mix Unicode and binary types provided that the binary strings were limited to 7-bit ASCII was the cause of a large number of bugs over the years, which Anglophones tended to overlook and allow to reach production code because they rarely use characters outside ASCII. Even as somebody generally very sympathetic to the needs of localisation, I've got this wrong because Python 2 had just too many ways to make mistakes in this area. In Python 3 you have to confront the distinction earlier and have a much better chance of getting it right. You can certainly begin to make the distinction in Python 2 code, but adding the extra type-safety required a breaking change. I'm not going to continue to spend time explaining the underlying reasons in response to vague insinuations, though. If there are some particular changes in Python 3 that you think weren't well-founded, name them. This is a list for developers; we can be specific. > So you go on to detail the similarities with C but with C there never was > one breaking point, just incremental changes. There have been many breaking changes in C over the years, though since it's an essentially smaller language most of those changes (not all!) have been at the runtime or library levels. Small consolation if that's what breaks your code, of course. But you seem to be under the impression that moving from Python 2 to Python 3 requires non-incremental changes: i.e. a flag day where your code stops working on Python 2 and starts working on Python 3. This isn't so. There's a large subset that works fine in both: nearly all the code I write these days is "bilingual" in this way, and the obvious porting strategy for most code involves making it be this way, so at the end all you have to do is flip to the newer interpreter after your tests pass. I would rather that Python 3 had taken the Perl 6 approach of having the newer interpreter be able to execute older code in a special compatibility mode, so that we could mix-and-match more freely and the transition would have been easier. On the other hand, it's not at all obvious how text/bytes types would have worked across the boundary. (And, much though I like Perl, Perl 6 has taken even longer to get into typical developers' hands than Python 3 has, so ...) > The work of "God" (unfortunate events) should not be willfully perpetrated > by humans on one another on purpose. What is your *concrete* proposal here? Bear in mind that we don't have the resources to maintain Python 2 indefinitely; if that's your proposal, it's going to run up against real-world constraints. But there may be other things we can do to make it easier for people. Do you have some specific projects that are troublesome? -- Colin Watson [cjwat...@ubuntu.com] -- 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: Python2 demotion (moving from main to universe) in progress
On Fri, Dec 08, 2017 at 09:51:00PM +0100, Xen wrote: > It was pushed upon an unwilling community Oh, please. I don't think anyone's going to argue that it's been the best-managed transition in the history of ever: it's true that it effectively split the community for a while, a lot of work has had to be put into porting work that might otherwise have been spent on other things, and we're still in a situation where many newer facilities have remained inaccessible to developers of older projects for longer than they ordinarily would have done. None of these things is anything like ideal. But framing it as a dichotomy between those nasty developers and an unwilling community of consumers is facile; it is by no means that simple. Plenty of folks in the Python community have recognised that, even if it isn't an ideal situation, there are good reasons behind many of the changes in Python 3 and they've put lots of energy into helping out. In any case, there is really very little point in tilting at this windmill now, unless your goal is to expend further energy. > But I was going to say 2 years might seem like a lot, or 3 years, but it is > nothing. It's been obvious for nearly ten years now that Python 2 was going to reach the end of the road eventually; once the incompatible changes to the language landed, it was naïve to expect that Python 2 would continue to be maintained indefinitely. Anybody who's only suddenly noticing it really hasn't been paying attention at all. > Meanwhile we can still run C programs from 1980, basically. > > Or whereabouts, at least. Interesting you should say that, because (just to take one example) the attitude to undefined behaviour in compilers has changed a great deal since 1980. Your C program written back then may still manage to compile with sufficient "please run in ancient mode" compiler options, but will it behave as expected if nobody has maintained it in nearly 40 years? Who can say, but probably only if it's very simple and you're quite lucky. And in fact unless it's the simplest possible kind of program with almost no system dependencies, you'll probably have to spend at least some effort bringing it up to date with post-Neolithic header names and function signatures. Admittedly I only have experience of maintaining moderate-sized C programs that hailed from the 1990s rather than the 1980s, but in my experience the work involved in keeping that sort of thing up to date isn't significantly different from the work involved in doing the same for similarly-sized Python projects. (That is, if it's more than a couple of thousand lines or so then somebody probably needs to be actively maintaining the thing even if its basic functionality is static, and you're going to have to occasionally deal with changes in the language or its runtime facilities, changes in your dependencies, and stuff you just missed.) > I think you can definitely find a way to compile most programs from 1990... Similarly, I'm sure it will remain possible to dig up Python 2 and continue to use it for many years to come, even after it's no longer supported upstream and no longer in Ubuntu. Whether that's a good idea after nobody is taking responsibility for security updates to the core language or the standard library, and after the libraries you depend on have dropped Python 2 support so you're stuck on older versions, is up to you to decide. If it's at all network-facing, then anyone with a reasonable sense of responsibility realised some time ago that they need to keep their dependencies up to date. If it's entirely self-contained, then maybe it's fine; to save on maintaining your own Python build, you could perhaps run it in a container running an older version of the OS. Or if the program is simple you may well just be able to run 2to3 over it and at least get most of the way there. But unless it's really enormous, it's probably not all that hard to port anyway. Putting a clear bytes/text distinction in place if you didn't have one already can be tedious, sure, but it generally makes things better; most of the rest is easy by comparison; and nowadays there are several good libraries and strategies to help. Lest anyone think I'm casually underestimating the work involved, I'm speaking here as a Launchpad developer: three-quarters of a million lines of Python code, and a couple of hundred dependencies. Sure, we're still on Python 2, which is a problem: other projects have generally taken precedence and porting has been a back-burner task. But a large part of the work we need to do is work we'd have needed to do anyway, such as bringing many of those dependencies up to date or finding better-maintained versions of some of them, and we have at least the skeleton of a plan. I feel quite safe in saying that for most Python programs it would be a great deal easier than this. -- Colin Watson [cjwat...@ubuntu
Re: Python SNI
On Thu, Nov 16, 2017 at 08:14:39PM +, Lee Jones wrote: > We want to avoid installing Python from source if possible - we run a > mission critical system in production and need to ensure that we use > the version of Python provided with Ubuntu; our view is that this > version is stable and installing a version from source could lead to > compatibility issues. > > We appreciate that Stable Release Updates policy, however we were > wondering if SNI could be considered for backporting based on a > security concern? Over the past twelve months SNI has grown in > popularity and many web hosting companies have now adopted it. Without > supporting SNI, it is not possible to verify the common name in the > website SSL certificate with the website domain. One thing I'd say is that this does carry a somewhat higher risk of regressions for users of the package than usual. When we upgraded launchpad.net from Ubuntu 12.04 to 16.04 earlier this year, we of course ended up with the SNI changes as a result, but because it was part of a scheduled upgrade we were able to make most of the code changes that we had to make to cope with this in advance. (For example, we now have to tell python-openid about the certificate of our test OpenID provider in our test suite, which we couldn't do before because urllib2.urlopen didn't take a "cafile" argument in earlier versions of Python.) Even with that preparation, we missed a bit and suffered a regression in production related to commercial subscriptions (https://bugs.launchpad.net/launchpad/+bug/1688361). As a scheduled upgrade, though, this was something we could deal with and gain most of the assurance we needed in advance by running our test suite on 16.04; it would have been much more problematic if it had suddenly appeared as part of routine stable upgrades. The SNI changes to Python are pretty extensive and touch quite a few modules. If I were in your position, I would instead be organising a scheduled upgrade to 16.04. (Indeed, I pretty much was in your position earlier this year - Launchpad is a mission-critical production site - and this is exactly what we did.) This would bring in the SNI changes as well as many other improvements; you're going to have to do it anyway eventually; and it wouldn't carry the same risk of regressions for other users. I'm not in a position to answer for Ubuntu's Python maintenance; this is just some perspective as a user. -- Colin Watson [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Bug#881692: command-not-found: I re-wrote command-not-found
On Thu, Nov 16, 2017 at 05:10:19PM -0800, Shawn Landden wrote: > On Mon, Nov 13, 2017 at 11:50 PM, Julian Andres Klode <j...@debian.org> > wrote: > > * It needs to be translated - also very important. > > I made a pot file and used translations from the python version, but I > can't get my app to look for translations (as examined through strace). I > read the gettext manual and do not know what I am doing wrong. Looking at https://github.com/shawnl/command-not-found/blob/master/command-not-found.c, your problem appears to be that you aren't calling setlocale(). You should normally call this before calling bindtextdomain() and textdomain(): setlocale(LC_ALL, ""); (The gettext manual does cover this, but possibly you were looking at some different bit of it.) -- Colin Watson [cjwat...@ubuntu.com] -- 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: aptitude's libicu56 dependency
On Mon, Sep 25, 2017 at 10:58:05AM +, Brian Haslett wrote: > I was cleaning out my system of orphaned packages the other day and I > couldn't help but notice that aptitude is linked with libicu56 > libraries but doesn't list the package as a dependency. I'm using the > "artful" flavor of ubuntu. I've just checked, and aptitude doesn't appear to be linked with libicu56 in artful. Exactly what command are you running that shows that this linkage exists? -- Colin Watson [cjwat...@ubuntu.com] -- 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: Compressed apt index files by default for 18.04?
On Sun, Sep 10, 2017 at 11:42:59AM +0200, Julian Andres Klode wrote: > On Sun, Sep 10, 2017 at 10:01:27AM +0100, Colin Watson wrote: > > Note that we'd need to get > > https://code.launchpad.net/~cjwatson/launchpad-buildd/apt-lists/+merge/286751 > > reviewed and landed before doing this, or dep-wait analysis of failed > > builds will break. > > I should mention that you don't need apt-helper, but can just pass > a file name to apt_pkg.TagFile and it handles decompression, starting > with libapt-pkg4.12 (which is about apt 1.0.9 I think?). I deliberately chose to use apt-helper instead, because it ensures that we're using tools from the chroot to parse files in the chroot, which is usually a good idea for robustness. If we used apt_pkg.TagFile outside the chroot, then we'd be reliant on python-apt in the buildd host system (i.e. a fixed Ubuntu series) being able to handle whatever formats are used in the chroot, which may be true now but seems a poor assumption to make in the long term. That said, if you think that would really be a better way to go about it, then please leave it as a comment on the MP otherwise we'll probably forget. -- Colin Watson [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
