Re: systemd-oomd issues on desktop
On Fri, Jun 10, 2022 at 1:49 AM Steve Langasek
wrote:
> On Thu, Jun 09, 2022 at 01:00:45PM -0400, Nick Rosbrook wrote:
> > In the reports I refer to above, applications are being killed due to
> > (1). In practice, the SwapUsedLimit might be too easy to reach on
> > Ubuntu, largely because Ubuntu provides just 1GB of swap. Since we
> > follow the suggestion of setting ManagedOOMSwap=kill on the root slice
> > [7], every cgroup is eligible for swap kill. When this condition is
> > met, user applications like browsers are going to be killed first.
>
> In terms of behavior that we want to see, this last sentence sets off red
> flags for me. There are times when, due to memory pressure, killing
> processes to reclaim memory is the right answer; and it is likely that the
> process using the most memory on a desktop system is the browser. But in
> terms of how a modern desktop is used, it's also quite likely that the
> browser is the most important process to the user experience on a desktop.
> (Cf. the Chromebook experience, where the browser effectively *is* the
> desktop.)
>
> I understand how we've arrived at the situation that browsers are the
> processes likely to be killed first when there's memory pressure; but
> separately from the question of what we should do for systemd-oomd overall,
> are there configuration changes we could make to lower the priority of the
> browser as a candidate for oom killing, and would those be reasonable
> configuration changes to make?
>
Also note that modern browsers (at least firefox and chrom{e,ium}) have
built-in mechanisms to discard/unload tabs they consider inactive to
reclaim memory, and these mechanisms are enabled by default. See
about:unloads in firefox, and chrome://discards in chromium. So it really
shouldn't be necessary to kill browsers the hard way.
Olivier
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Ubuntu bug reporting for snaps (was: Should we remove chromium-browser from the archive?)
On Tue, Feb 15, 2022 at 11:21 PM Brian Murray wrote: > > On Tue, Feb 08, 2022 at 09:18:41PM +0100, Olivier Tilloy wrote: > > On Tue, Feb 8, 2022 at 8:57 PM Sebastien Bacher wrote: > > > > > > Hey Olivier, thanks for raising the topic! > > > > > > Le 08/02/2022 à 19:33, Olivier Tilloy a écrit : > > > > - a custom apport hook that collects additional information about the > > > > snap and its dependencies > > > > > > I'm going to sidetrack slightly the discussion in a new topic to address > > > that point. I think that's a problem we need to resolve for snaps. We > > > added some hooks to apport directly for subiquity or > > > ubuntu-desktop-installer but it would be better if ubuntu-bug was able > > > to find hooks provided by the snaps (either by having snapd exporting > > > them to a system location or by teaching ubuntu-bug to look into > > > /snap/<...>/current/. > > > > A good first step, not going as far as enabling snaps to expose custom > > hooks, would be for apport to attach standard additional information > > when reporting a bug for a snap (in the add_snap_info function?): > > > > - snap changes --abs-time $SNAPNAME > > - snap connections $SNAPNAME > > - snap info --abs-time $SNAPNAME > > - for PROVIDER in $(grep default-provider > > /snap/$SNAPNAME/current/meta/snap.yaml | uniq | cut -d: -f2); do snap > > info --abs-time $PROVIDER; done > > - snap info --abs-time $(grep base: > > /snap/$SNAPNAME/current/meta/snap.yaml | cut -d: -f2) > > I've gone ahead and created http://launchpad.net/bugs/1960964 to track > this, please update the bug if I missed anything. I'll try and get this > done before the release of Jammy. Excellent, thanks Brian! -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Should we remove chromium-browser from the archive?
On Tue, Feb 8, 2022 at 7:33 PM Olivier Tilloy
wrote:
>
> The chromium-browser package has been a "transitional" package that
> installs the chromium snap since Ubuntu 19.10. Full-fledged deb
> packages are still being built for 18.04.
>
> The question of whether to remove this transitional package from the
> archive altogether has come up, so I'm sharing it here to get insights
> and feedback from a wider audience before making an informed decision.
>
> Some features of the deb package that are worth taking into account:
> - /usr/bin/{chromium-browser,chromedriver} symlinks to their snap
> counterparts
> - a postinst script that installs alternatives for x-www-browser and
> gnome-www-browser (unfortunately snapd doesn't have any mechanism for
> this yet)
> - a custom apport hook that collects additional information about the
> snap and its dependencies
> - did I miss any other features?
>
> Orthogonal to this, it's been reported that the version number of the
> deb is confusing, because it contains a random outdated chromium
> version, but this can be addressed separately if the package remains
> in the archive with the use of an epoch to reset the version scheme to
> something saner.
>
> I welcome your thoughts on the matter.
Thanks to everyone who shared their thoughts on the matter.
There are indeed compelling reasons to keep chromium-browser in the
archive for now, at least until snapd provides tighter integration
with the host system, so it is staying.
I'm of course happy to revisit this decision at a later time in light
of new arguments.
Olivier
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Should we remove chromium-browser from the archive?
On Wed, Feb 9, 2022 at 10:44 AM Jeremy Bicha wrote: > > On Wed, Feb 9, 2022 at 4:13 AM Olivier Tilloy > wrote: > > > 18.04 users upgrading to 22.04 will expect that their profile > > > (bookmarks, cookies, passwords, settings) from the full chromium package > > > isn't lost. How will this be guaranteed if the transitional package is > > > dropped? > > > > Their profile won't be lost, as uninstalling the deb leaves the > > profile directory untouched. > > However it is true that dist-upgrading from 18.04 to 22.04 would > > result in chromium being uninstalled, and users would have to manually > > re-install the snap (which would then pick up the existing profiles). > > Not a nice user experience. > > We don't support skipping LTS releases when upgrading. Right, I wasn't sure anymore. So the upgrade path would be 18.04 to 20.04, chromium-browser is updated and installs the chromium snap, then 20.04 to 22.04, chromium-browser is removed but the snap was previously installed. Not such a bad UX, after all. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Should we remove chromium-browser from the archive?
On Tue, Feb 8, 2022 at 8:38 PM Thomas Ward wrote:
>
> Not to mention, the rdepends of the package:
>
> # apt-cache rdepends chromium-browser
> chromium-browser
> Reverse Depends:
> chromium-browser-l10n
> gnome-shell-extension-gsconnect-browsers
> |gnome-core
> chromium-chromedriver
> chrome-gnome-shell
> chrome-gnome-shell
>
> We'd have to do some erasure of some packages (potentially transitional) and
> some other packages as well as a few shell extensions in order to make this
> removal work I think.
chromium-browser-l10n and chromium-chromedriver are built from the
same chromium-browser source package.
gnome-shell-extension-gsconnect-browsers and chrome-gnome-shell only
suggest chromium-browser, it's not a hard dependency.
gnome-core does depend on chromium-browser, but it's OR'ed with other browsers:
firefox-esr (>= 78) | firefox (>= 78) | chromium |
chromium-browser | epiphany-browser
At this point it looks like the benefits of keeping the package in the
archive largely outweigh those of removing it anyway.
> On 2/8/22 14:29, Gunnar Hjalmarsson wrote:
>
> Hi Olivier!
>
> On 2022-02-08 19:33, Olivier Tilloy wrote:
>
> The chromium-browser package has been a "transitional" package that
> installs the chromium snap since Ubuntu 19.10. Full-fledged deb
> packages are still being built for 18.04.
>
> The question of whether to remove this transitional package from the
> archive altogether has come up, so I'm sharing it here to get insights
> and feedback from a wider audience before making an informed decision.
>
> Some features of the deb package that are worth taking into account:
> - /usr/bin/{chromium-browser,chromedriver} symlinks to their snap
> counterparts
> - a postinst script that installs alternatives for x-www-browser and
> gnome-www-browser (unfortunately snapd doesn't have any mechanism for
> this yet)
> - a custom apport hook that collects additional information about the
> snap and its dependencies
> - did I miss any other features?
>
>
> Can't tell, but those are important enough, aren't they?
>
> Your message made me think of bugs like these:
>
> https://launchpad.net/bugs/1947600
>
> https://launchpad.net/bugs/1950550
>
> And today I had a reason to install xsane.
>
> $ apt-cache show xsane | grep Recommends
> Recommends: cups-client, firefox | www-browser
>
> As you see it pulled the Firefox .deb even if I have the Firefox snap
> installed.
>
> So as long as there is no other mechanism to make the system recognize the FF
> snap and/or the Chromium snap as a www-browser, I suppose we need such
> transitional packages. (Waiting for the FF equivalent.)
>
> --
> ubuntu-devel mailing list
> ubuntu-devel@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Should we remove chromium-browser from the archive?
On Tue, Feb 8, 2022 at 8:30 PM Gunnar Hjalmarsson wrote:
>
> Hi Olivier!
>
> On 2022-02-08 19:33, Olivier Tilloy wrote:
> > The chromium-browser package has been a "transitional" package that
> > installs the chromium snap since Ubuntu 19.10. Full-fledged deb
> > packages are still being built for 18.04.
> >
> > The question of whether to remove this transitional package from the
> > archive altogether has come up, so I'm sharing it here to get insights
> > and feedback from a wider audience before making an informed decision.
> >
> > Some features of the deb package that are worth taking into account:
> > - /usr/bin/{chromium-browser,chromedriver} symlinks to their snap
> > counterparts
> > - a postinst script that installs alternatives for x-www-browser and
> > gnome-www-browser (unfortunately snapd doesn't have any mechanism for
> > this yet)
> > - a custom apport hook that collects additional information about the
> > snap and its dependencies
> > - did I miss any other features?
>
> Can't tell, but those are important enough, aren't they?
Yes, they are indeed.
> Your message made me think of bugs like these:
>
> https://launchpad.net/bugs/1947600
>
> https://launchpad.net/bugs/1950550
>
> And today I had a reason to install xsane.
>
> $ apt-cache show xsane | grep Recommends
> Recommends: cups-client, firefox | www-browser
>
> As you see it pulled the Firefox .deb even if I have the Firefox snap
> installed.
>
> So as long as there is no other mechanism to make the system recognize
> the FF snap and/or the Chromium snap as a www-browser, I suppose we need
> such transitional packages. (Waiting for the FF equivalent.)
Definitely a strong argument in favour of keeping the package around.
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Should we remove chromium-browser from the archive?
On Tue, Feb 8, 2022 at 7:45 PM Heinrich Schuchardt
wrote:
>
> On 2/8/22 19:33, Olivier Tilloy wrote:
> > The chromium-browser package has been a "transitional" package that
> > installs the chromium snap since Ubuntu 19.10. Full-fledged deb
> > packages are still being built for 18.04.
> >
> > The question of whether to remove this transitional package from the
> > archive altogether has come up, so I'm sharing it here to get insights
> > and feedback from a wider audience before making an informed decision.
> >
> > Some features of the deb package that are worth taking into account:
> > - /usr/bin/{chromium-browser,chromedriver} symlinks to their snap
> > counterparts
> > - a postinst script that installs alternatives for x-www-browser and
> > gnome-www-browser (unfortunately snapd doesn't have any mechanism for
> > this yet)
> > - a custom apport hook that collects additional information about the
> > snap and its dependencies
> > - did I miss any other features?
> >
> > Orthogonal to this, it's been reported that the version number of the
> > deb is confusing, because it contains a random outdated chromium
> > version, but this can be addressed separately if the package remains
> > in the archive with the use of an epoch to reset the version scheme to
> > something saner.
> >
> > I welcome your thoughts on the matter.
> >
> > Thanks,
> >
> > Olivier
> >
>
> 18.04 users upgrading to 22.04 will expect that their profile
> (bookmarks, cookies, passwords, settings) from the full chromium package
> isn't lost. How will this be guaranteed if the transitional package is
> dropped?
Their profile won't be lost, as uninstalling the deb leaves the
profile directory untouched.
However it is true that dist-upgrading from 18.04 to 22.04 would
result in chromium being uninstalled, and users would have to manually
re-install the snap (which would then pick up the existing profiles).
Not a nice user experience.
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Ubuntu bug reporting for snaps (was: Should we remove chromium-browser from the archive?)
On Tue, Feb 8, 2022 at 8:57 PM Sebastien Bacher wrote: > > Hey Olivier, thanks for raising the topic! > > Le 08/02/2022 à 19:33, Olivier Tilloy a écrit : > > - a custom apport hook that collects additional information about the > > snap and its dependencies > > I'm going to sidetrack slightly the discussion in a new topic to address > that point. I think that's a problem we need to resolve for snaps. We > added some hooks to apport directly for subiquity or > ubuntu-desktop-installer but it would be better if ubuntu-bug was able > to find hooks provided by the snaps (either by having snapd exporting > them to a system location or by teaching ubuntu-bug to look into > /snap/<...>/current/. A good first step, not going as far as enabling snaps to expose custom hooks, would be for apport to attach standard additional information when reporting a bug for a snap (in the add_snap_info function?): - snap changes --abs-time $SNAPNAME - snap connections $SNAPNAME - snap info --abs-time $SNAPNAME - for PROVIDER in $(grep default-provider /snap/$SNAPNAME/current/meta/snap.yaml | uniq | cut -d: -f2); do snap info --abs-time $PROVIDER; done - snap info --abs-time $(grep base: /snap/$SNAPNAME/current/meta/snap.yaml | cut -d: -f2) Of course, custom hooks would be a nice addition. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Should we remove chromium-browser from the archive?
The chromium-browser package has been a "transitional" package that
installs the chromium snap since Ubuntu 19.10. Full-fledged deb
packages are still being built for 18.04.
The question of whether to remove this transitional package from the
archive altogether has come up, so I'm sharing it here to get insights
and feedback from a wider audience before making an informed decision.
Some features of the deb package that are worth taking into account:
- /usr/bin/{chromium-browser,chromedriver} symlinks to their snap counterparts
- a postinst script that installs alternatives for x-www-browser and
gnome-www-browser (unfortunately snapd doesn't have any mechanism for
this yet)
- a custom apport hook that collects additional information about the
snap and its dependencies
- did I miss any other features?
Orthogonal to this, it's been reported that the version number of the
deb is confusing, because it contains a random outdated chromium
version, but this can be addressed separately if the package remains
in the archive with the use of an epoch to reset the version scheme to
something saner.
I welcome your thoughts on the matter.
Thanks,
Olivier
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Application for Core Developer (gunnarhj)
On Mon, Apr 5, 2021 at 5:36 PM 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! Congratulations Gunnar! -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
+1 maintenance report
Hello everyone, This week I did a 2-day shift, following is a report of what I accomplished. libsndfile was FTBFS on riscv64, I filed https://launchpad.net/bugs/1917650 and uploaded https://launchpad.net/ubuntu/+source/libsndfile/1.0.31-1ubuntu1, which built and migrated successfully. gjs autopkgtests are failing, I filed 3 upstream bugs and submitted corresponding PRs, which all got merged. I cherry-picked the fixes as patches and submitted https://salsa.debian.org/gnome-team/gjs/-/merge_requests/16, it's waiting on Trevinho to merge and upload to experimental, then sync to hirsute. I completed the evolution-data-server transition (which was blocking 14 other packages). This involved: - getting an AA to move evolution-data-server-tests back to universe to fix a components mismatch (thanks seb128) - fixing libedataserver1.2-dev to depend on libgdata-dev (https://salsa.debian.org/gnome-team/evolution-data-server/-/merge_requests/3) - uploading no-change rebuilds of folks and gnome-contacts - pushing build fixes to lp:indicator-datetime and uploading a new version Similar to the fixes for indicator-datetime, I fixed the build of ayatana-indicator-datetime (https://github.com/AyatanaIndicators/ayatana-indicator-datetime/pull/25) and it successfully migrated. Finally I worked on the libraw transition. The package was FTBFS on ppc64el, I submitted https://salsa.debian.org/debian-phototools-team/libraw/-/merge_requests/5, I filed https://launchpad.net/bugs/1917756 and I uploaded the fix. I then uploaded no-change rebuilds for theli, nomacs, luminance-hdr, openimageio, libkf5kdcraw, freeimage, efl, kstars, krita, kodi-imagedecoder-raw, hdrmerge, entangle, deepin-image-viewer, shotwell. Some of those are still building at the time I'm writing this report. krita won't build on armhf because it's missing libqt5opengl5-desktop-dev, but the version in the archive already has this shortcoming, so not a regression. kodi-imagedecoder-raw won't build on arm* and riscv64 because kodi is FTBFS on these architectures, I'm testing a rebuild of kodi in a PPA at the moment. A couple of libraw reverse dependencies needed additional fixes to build successfully: siril (I cherry-picked https://gitlab.com/free-astro/siril/-/commit/d319fce) and gegl (I submitted https://gitlab.gnome.org/GNOME/gegl/-/merge_requests/93). I'll continue to oversee the libraw transition until it's complete. Have a good week-end, Olivier -- 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, Feb 5, 2021 at 5:00 PM Olivier Tilloy wrote: > > Hello everyone, > > This week I focused my 2-day shift on ruby-rugged, which is the last > blocker preventing libgit2 from migrating. > I had no prior experience with ruby so I learnt a few things along the way. > I uploaded https://launchpad.net/ubuntu/+source/ruby-rugged/1.1.0+ds-3ubuntu2, > which fixed the ruby-rugged autopkgtests. > Next I looked at ruby-licensee whose autopkgtests were failing because > of a version dependency mismatch with ruby-rugged. > I synced 9.14.1-1 from Debian experimental then uploaded > https://launchpad.net/ubuntu/+source/ruby-licensee/9.14.1-1ubuntu1 > (including two patches submitted to Debian − > https://salsa.debian.org/ruby-team/ruby-licensee/-/merge_requests/1 > and https://salsa.debian.org/ruby-team/ruby-licensee/-/merge_requests/2). > I then had to retry the ruby-gollum-rugged-adapter tests with an > additional trigger on the version in hirsute-proposed > (0.4.4.3~gitlab.1-1). > > At the time of writing, ruby-rugged hasn't migrated yet because the > hirsute armhf queue for autopkgtests is huge and processing slowly, > but it's otherwise looking good. > Once it does migrate, libgit2 should be able to follow suit, and with > it a number of reverse dependencies (calligra, criterion, fritzing, > geany-plugins, gnome-builder, gnuastro, horizon-eda, julia, > kup-backup, libgit-raw-perl, libgit2-glib, python-pygit2, rust-bat, > rust-git-absorb). As a follow-up, I uploaded https://launchpad.net/ubuntu/+source/ruby-licensee/9.14.1-1ubuntu2 to address autopkgtest failures on armhf, and with that ruby-licensee migrated, followed by ruby-rugged and all its reverse dependencies listed above. > I started to assess the status of gitaly, which is new in hirsute, and > depends on ruby-rugged. This will require upstream commit > https://gitlab.com/gitlab-org/gitaly/-/commit/0d1a7a18f26136453e781b011b3c1b9ab5f011f7, > but Debian is lagging behind a few upstream versions and doesn't have > this yet. > To build gitaly 13.6.5 (currently in salsa), we'll need > ruby-gitlab-labkit 0.13.2-2 from Debian experimental, which in turn > requires ruby-jaeger-client 1.1.0-1 from experimental too. Even with > those installed in a hirsute chroot, gitaly 13.6.5 is FTBFS. This will > require additional work, but I ran out of time, and gitaly isn't > blocking anything else, so not a high priority I guess. > > Have a good week-end, > > Olivier -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
+1 maintenance report
Hello everyone, This week I focused my 2-day shift on ruby-rugged, which is the last blocker preventing libgit2 from migrating. I had no prior experience with ruby so I learnt a few things along the way. I uploaded https://launchpad.net/ubuntu/+source/ruby-rugged/1.1.0+ds-3ubuntu2, which fixed the ruby-rugged autopkgtests. Next I looked at ruby-licensee whose autopkgtests were failing because of a version dependency mismatch with ruby-rugged. I synced 9.14.1-1 from Debian experimental then uploaded https://launchpad.net/ubuntu/+source/ruby-licensee/9.14.1-1ubuntu1 (including two patches submitted to Debian − https://salsa.debian.org/ruby-team/ruby-licensee/-/merge_requests/1 and https://salsa.debian.org/ruby-team/ruby-licensee/-/merge_requests/2). I then had to retry the ruby-gollum-rugged-adapter tests with an additional trigger on the version in hirsute-proposed (0.4.4.3~gitlab.1-1). At the time of writing, ruby-rugged hasn't migrated yet because the hirsute armhf queue for autopkgtests is huge and processing slowly, but it's otherwise looking good. Once it does migrate, libgit2 should be able to follow suit, and with it a number of reverse dependencies (calligra, criterion, fritzing, geany-plugins, gnome-builder, gnuastro, horizon-eda, julia, kup-backup, libgit-raw-perl, libgit2-glib, python-pygit2, rust-bat, rust-git-absorb). I started to assess the status of gitaly, which is new in hirsute, and depends on ruby-rugged. This will require upstream commit https://gitlab.com/gitlab-org/gitaly/-/commit/0d1a7a18f26136453e781b011b3c1b9ab5f011f7, but Debian is lagging behind a few upstream versions and doesn't have this yet. To build gitaly 13.6.5 (currently in salsa), we'll need ruby-gitlab-labkit 0.13.2-2 from Debian experimental, which in turn requires ruby-jaeger-client 1.1.0-1 from experimental too. Even with those installed in a hirsute chroot, gitaly 13.6.5 is FTBFS. This will require additional work, but I ran out of time, and gitaly isn't blocking anything else, so not a high priority I guess. Have a good week-end, Olivier -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
+1 maintenance report
Hello everyone, I was scheduled for two full days of +1 maintenance duty this week (Wednesday and Thursday), but other urgent tasks meant I only did it part-time and spread over 3 days. Here are some notes of what I looked into and the actions I took (also including notes from a partial shift I did two weeks ago). gettext was FTBFS on armhf (https://launchpad.net/bugs/1910792), I cherry-picked an upstream commit to fix it, and uploaded 0.21-3ubuntu1. It was then FTBFS on i386 because dh-elpa pulls in [emacs-nox | emacs] which isn't built on i386. Laney suggested moving dh-elpa to Build-Depends-Indep, and I ended up doing that but with dh-sequence-elpa instead, which required a dh-elpa upload (2.0.6ubuntu1), after which I uploaded gettext 0.21-3ubuntu2. This should unblock the following: * FTBFS on i386 caused by a b-d on gettext: gnulib * b-d on gettext: gkdebconf, puppetlabs-i18n-clojure * depends on gettext: kdesdk-thumbnailers, poxml, wine emacs was FTBFS on almost all architectures, this was caused by new unit tests requiring DNS lookup (https://launchpad.net/bugs/1911209). I uploaded 1:27.1+1-3ubuntu2 with a patch to skip those tests. After that, s390x was still FTBFS because of a consistently failing unit test (https://launchpad.net/bugs/1911236), I spent a bit of time investigating it and found that the regression most likely happened with the toolchain update in Groovy, but I didn't go to the bottom of it, and xnox did a new upload (1:27.1+1-3ubuntu3) skipping that test. The bug remains open for future investigation. rust-smallvec autopkgtests failed on all architectures because of using const generics. I re-ran them with an additional trigger on rustc 1.47.0 in -proposed, and it successfully migrated. glib-d is FTBFS on armhf, riscv64 and s390x. On architectures where it builds successfully, the D compiler used is ldc2. Where it fails to build, gdc is used. I tested building with ldc2 on armhf (by hand-editing /usr/share/dh-dlang/dlang-flags.mk to whitelist it) and the build succeeded, so it looks like a gdc bug to me. Building with ldc2 on all architectures is not an option, because it's only available on amd64, arm64 and armhf. So we need to look into that gdc bug, but I'm D-illiterate and I ran out of time. Olivier -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: New Ubuntu Core Developer - Lukas Märdian
On Mon, Dec 14, 2020 at 6:17 PM Lukasz Zemczak wrote: > > Hello everyone! > > We are pleased to announce that at today's DMB meeting slyon has been > accepted into the Ubuntu Core Developer family! Welcome aboard! Congratulations Lukas, and welcome aboard! -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Running autopkgtests from PPA on real infrastructure
On Wed, Sep 16, 2020 at 5:13 PM Iain Lane wrote: > > On Tue, Sep 15, 2020 at 03:53:01PM +0200, Lukas Märdian wrote: > > * Upload your package (incl. debian/tests/*) to your PPA > > * Get a core-dev/MOTU to trigger the test for you, via this URL scheme: > > https://autopkgtest.ubuntu.com/request.cgi?release=RELEASE&arch=ARCH&package=SRCPKG > > *&ppa=LPUSER/PPA*&trigger=SRCPKG/VERSION > > * Check the results via this URL scheme: > > https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-RELEASE-LPUSER-PPA/ > > I would dearly love to improve this situation. I could imagine (easier) > a CLI tool to help you > > (1) submit requests, > > (2) view them [the swift software we use to store/retrieve results has > an API], I wrote a couple of scripts that cater well for my particular use cases: I build multiple versions of firefox, thunderbird and chromium-browser in various PPAs, and I wanted to be able to request tests for a particular version prefix (potentially spanning several releases) in a given PPA, and to quickly view a summary of the test results. The code is at https://code.launchpad.net/~osomon/+git/ubuntu-scripts, and the interesting scripts are request-autopkgtests.py and display-filtered-autopkgtests-results-summary.py. Example use case: ./request-autopkgtests.py ppa:ubuntu-mozilla-security/ppa firefox 81 # after all the tests have completed (check periodically at http://autopkgtest.ubuntu.com/running) ./display-filtered-autopkgtests-results-summary.py ppa:ubuntu-mozilla-security/ppa firefox bionic 20200916 I use those scripts daily and they're a big time saver. Suggestions and improvements welcome, and I'm happy to work towards having them owned and maintained by ~ubuntu-dev if they can be of use. > or (harder, better) an extension to the web frontend so that PPA results > are displayed like distro ones. > > Just mentioning this in case anyone gets excited about helping with the > tooling. I'd love to put this on my list, but someone else picking it up > would make it happen sooner. :) Cheers, Olivier -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Running autopkgtests from PPA on real infrastructure
On Wed, Sep 16, 2020 at 1:07 PM Lukas Märdian wrote: > > Hello all, > > I'm currently working on a problem where an autopkgtest works fine in local > autopkgtest testrunners (QEMU based), but it fails in different ways on the > real Ubuntu autopkgtest infrastructure [0] (networking related issues). > > Some developers use Bileto [1] to reproduce tests in such situations. But not > everybody has access to Bileto and it comes with bigger overhead, due to > running all reverse-depends tests as well. > > I found out about another way of running autopkgtests on the real > infrastructure, using a PPA. The approach is documented in the wiki [2], but > lots of people seemed to be surprised about it, so this is a heads up that > this approach exists and works! > > Basically: > * Upload your package (incl. debian/tests/*) to your PPA > * Get a core-dev/MOTU to trigger the test for you, via this URL scheme: A clarification: no need for a core-dev/MOTU if you have upload rights for that package in Ubuntu. In that case you can trigger the test yourself. The ubuntu-upload-permission tool in ubuntu-dev-tools is handy to check whether you are allowed to upload (and therefore to trigger tests for) a given source package. > https://autopkgtest.ubuntu.com/request.cgi?release=RELEASE&arch=ARCH&package=SRCPKG&ppa=LPUSER/PPA&trigger=SRCPKG/VERSION > * Check the results via this URL scheme: > https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-RELEASE-LPUSER-PPA/ > > Best, >Lukas > > [0] https://autopkgtest.ubuntu.com/ > [1] https://bileto.ubuntu.com/ > [2] https://wiki.ubuntu.com/ProposedMigration#Testing_against_a_PPA > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: chromium-browser epoch bump for transitional package?
On Thu, Aug 13, 2020 at 2:47 AM Steve Langasek wrote: > > On Wed, Aug 12, 2020 at 01:31:54PM +0100, Robie Basak wrote: > > In doing SRU reviews today, I came across LP: #1889106 which is a > > request for a no-change rebuild to bump the version so it beats the > > versions presented in previous releases. > > > > The problem is real, but it seems suboptimal to me to keep fixing it > > this way. We'll need to keep SRUing chromium-browser to Focal (and later > > releases presumably). Every time we do that, all users (who have the > > transitional package) get yet another update to download, even if it is > > small. And every time it takes both Olivier's and the SRU team's time. > > > > Would an epoch bump be a better option here? Debian doesn't currently > > carry a package with that name, so we're already diverged enough that I > > don't forsee a problem from there. > > I agree that an epoch bump on the transitional .deb in focal is a reasonable > solution for this issue. To follow up on this issue, I uploaded chromium-browser 1:84.0.4147.135-0ubuntu1 to groovy yesterday, and I will SRU to focal as soon as the current SRU hits focal-updates. Thanks Robie for suggesting this solution, and Dimitri and Steve for validating it. Olivier -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
+1 maintenance status − July 09-10
Hello everyone, I was on +1 maintenance shift last Thursday and Friday. I focused solely on node-* test failures that are blocking the migration of nodejs 12.18.1. I got side-tracked quite a bit, so I didn't manage to do as much as I intended, but I'm going to continue poking at it throughout the week. This has become more urgent as the new britney deployed by Laney last week is now blocking on build dependencies, meaning firefox updates are now blocked because of nodejs. So far I identified the following classes of problems with node-* autopkgtests: - package needs a no-change rebuild against the bumped soname for libnode.so (e.g. node-iconv) - tests depending on node-iconv need an additional trigger to pick up the rebuilt version (e.g. node-body-parser) - tests require patching because of API/behaviour changes in the new Node.js (e.g. node-buffer-shims or node-diff) - sha.js's SHA-1 implementation is failing on ppc64el, causing various packages depending on it to fail on this architecture ( https://launchpad.net/bugs/1887144) - a few flaky tests pass with a retry Help appreciated (particularly on that sha.js issue)! Have a good week, Olivier -- 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 status − June 18-19
On Wed, Jun 24, 2020 at 7:59 PM Brian Murray wrote: > On Fri, Jun 19, 2020 at 08:03:56PM +0200, Olivier Tilloy wrote: > > Hello everyone, > > > > I was on +1 maintenance shift this Thursday and Friday. > > This is what I managed to get through: > > > > * rocksdb FTBFS: filed https://launchpad.net/bugs/1884072, > > cherry-picked one upstream patch and wrote another trivial one, > > attached debdiff to the bug report, needs sponsoring (but low priority > > because the new upstream version that is available in experimental > > builds fine) > > * python-cogent: looked at autopkgtests failures, but I couldn't > > reproduce them locally, I asked for retries with various triggers, but > > no luck > > I'm curious how you ran the python-cogent autopkgtests as I was able to > recreate the failure using qemu as the virtualization server during one > of my previous +1 shifts. > I had used a groovy chroot on my focal laptop, admittedly a different environment than what's used to run autopkgtests. I tried again today, using the lxd virtualization server (supposedly much closer to the real thing), and it's still happily passing here. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
+1 maintenance status − June 18-19
Hello everyone, I was on +1 maintenance shift this Thursday and Friday. This is what I managed to get through: * rocksdb FTBFS: filed https://launchpad.net/bugs/1884072, cherry-picked one upstream patch and wrote another trivial one, attached debdiff to the bug report, needs sponsoring (but low priority because the new upstream version that is available in experimental builds fine) * python-cogent: looked at autopkgtests failures, but I couldn't reproduce them locally, I asked for retries with various triggers, but no luck * libvorbis: the autopkgtests depended on a python2 package that had been removed from the archive, I filed https://bugs.debian.org/963082 and submitted https://salsa.debian.org/multimedia-team/libvorbis/-/merge_requests/1, and prepared an ubuntu debdiff which Balint kindly sponsored * gmenuharness: was removed in focal (https://launchpad.net/bugs/1866434) but crept back in (not sure how?), it should be removed again * got the libvorbis autopkgtests triggered by glibc 2.31-0ubuntu10 retried, and passed * libvoikko needed a no-change rebuild to update its dependencies to the bumped hfst-ospell soname (10 -> 11), so that hfst-ospell could migrate, I uploaded 4.3-1build2, and the migration proceeded * dh-python autopkgtest failures (https://launchpad.net/bugs/1883297, https://bugs.debian.org/956295), fixed with a combination of cherry-picking an upstream commit (https://salsa.debian.org/python-team/tools/dh-python/-/commit/e289c25) that hasn't been released yet, and disabling Python2 tests (as was done in version 4.20191017ubuntu4 in focal) − needs sponsoring (debdiff attached to the bug report) Have a good week-end, Olivier -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
+1 maintenance status − June 4-5
Hello everyone, I was on +1 maintenance shift this Thursday and Friday. This was my first time doing this, so a part of my shift was spent reading documentation, and getting familiar with the tools and processes. Many thanks to seb128 for mentoring me through it. Following is a summary of what I did in terms of actual +1 maintenance: * metis/i386: submitted a MR to add a force-badtest hint ( https://code.launchpad.net/~osomon/britney/hints-ubuntu-i386-badtests/+merge/385113 ) * fonts-dejavu: the transitional packages were removed, but a number of rdepends still listed them, so I went through all of them and filed bugs and submitted patches where relevant: * enigma-data: attached patch to https://bugs.debian.org/921469 * 0ad: not needed * frogatto-data: already done in 1.3.1+dfsg-2, needs releasing * astromenace: filed https://bugs.debian.org/962195 and submitted https://salsa.debian.org/games-team/astromenace/-/merge_requests/1 * zatacka (https://bugs.debian.org/961863): submitted https://github.com/alexdantas/zatacka.debian/pull/3 * xmoto-data (https://bugs.debian.org/946057): already done in 0.6.0+repack-1, currently in unstable (and in groovy-proposed) * singularity: filed https://bugs.debian.org/962196 and attached patch * scilab-test: filed https://bugs.debian.org/962198 and submitted https://salsa.debian.org/science-team/scilab/-/merge_requests/4 * sarg: filed https://bugs.debian.org/962200 and submitted https://salsa.debian.org/debian/sarg/-/merge_requests/1 * plymouth-theme-hamara: not needed * natbraille: filed https://bugs.debian.org/962201 and submitted https://salsa.debian.org/a11y-team/natbraille/-/merge_requests/1 * miceamaze: not needed * manaplus-data: filed https://bugs.debian.org/962207 and attached patch * libgazebo-dev: already done in 11.0.0+dfsg1-3 * icewm: not needed * castle-game-engine-doc (https://bugs.debian.org/961602): submitted https://salsa.debian.org/pascal-team/castle-game-engine/-/merge_requests/1 * blobwars-data: filed https://bugs.debian.org/962210 and attached patch * blobandconquer-data: filed https://bugs.debian.org/962211 and attached patch * mythtv*: filed https://launchpad.net/bugs/1882108 and submitted https://github.com/MythTV/packaging/pull/78 * wmforkplop (https://bugs.debian.org/861191): already done in 0.9.3-2.2 (uploaded to DELAYED/7 on 1st June) * fontforge FTBFS on s390x (preventing libreoffice from building there): https://bugs.debian.org/961841, identified and tested upstream commit that fixes the build ( https://github.com/fontforge/fontforge/commit/fde85b13382595cb3ab889e38570b4944edad808), and later realized that that commit has already been cherry-picked in salsa ( https://salsa.debian.org/fonts-team/fontforge/-/commit/ad2b5f648241de5920a6f7f738dea091290a0af0), it is now pending a release * r-cran-gwidgetstcltk test failures (blocking xorg-server): filed https://bugs.debian.org/962280 and submitted https://salsa.debian.org/r-pkg-team/r-cran-gwidgetstcltk/-/merge_requests/1 * glade/i386 test failures (badpkg) blocking gdk-pixbuf 2.40.0+dfsg-5: ran the tests locally and they passed, so I asked seb128 to re-trigger, and it succeeded Have a good week-end, Olivier -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: New Ubuntu Core Developer - Tiago Stürmer Daitx
On Wed, Nov 21, 2018 at 5:43 AM Simon Quigley wrote: > > Yesterday (Monday) Tiago was approved as an Ubuntu Core Developer by the > Ubuntu Developer Membership Board. He now has upload rights to the > entire Ubuntu archive. Congratulations Tiago! -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: New Ubuntu Core Developer - Andreas Hasenack
On Mon, Sep 24, 2018 at 7:54 PM Lukasz Zemczak wrote: > > Hello everyone, > > Please congratulate Andreas on his today's successful Ubuntu Core > Developer application! Great to have you on the team. Congrats Andreas! -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: New Ubuntu Core Developer - Simon Quigley
On Mon, Aug 13, 2018 at 10:27 PM Simon Quigley wrote: > > Today, I was voted to be an Ubuntu Core Developer by the Ubuntu > Developer Membership Board (a board which I already sit on, so I'm > taking care of myself here). I now have upload rights to the entire > Ubuntu archive. Congrats Simon! -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: New Ubuntu Developer - Olivier Tilloy
On Tue, Nov 21, 2017 at 5:41 PM, Jeremy Bicha wrote: > Hello, > > After a successful vote at yesterday's Developer Membership Board > meeting, we are pleased to announce that Olivier Tilloy (osomon) is > now the newest Ubuntu Developer. Olivier was granted upload rights for > chromium-browser. > > Congratulations and welcome! Thanks Jeremy, everyone on the DMB, and everyone who provided guidance and sponsored my uploads until now. I'm glad to be officially part of the family! Olivier -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Updating QtWebKit to 5.2
On Fri, May 30, 2014 at 8:29 AM, Dmitry Shachnev wrote: > Hi all, > > I would very much like to update qtwebkit-opensource-src to version > 5.2.0. It blocks syncs of other packages, like pyqt5, > qtsensors-opensource-src and qtscript-opensource-src. It is also a > prerequisite for updating Qt itself to version 5.3 (as qttools now > depends on qtwebkit). > > According to Timo in > > https://code.launchpad.net/~mitya57/kubuntu-packaging/qtwebkit-merge-with-debian/+merge/216539 > : > > > This looks it'd be great to have so I'm planning to build this for > testing in addition to qtbase > > and qtdeclarative when U opens, but we need to check with webapps people > (= dbarth, > > alex-abreu) on how they see this. > > > > I'm not clear on what's the schedule for full Oxide moving. In addition > to touch also desktop > > is currently including libqt5webkit5 in default install still (checked > with seeded-in-ubuntu > > qtwebkit-opensource-src). > > Does anybody know when it will be possible to upload this? > > I do not want to break Touch stuff, but I am already waiting for more > than a month and don't want to wait more. > As far as webbrowser-app is concerned, the transition to oxide is complete. The webapp-container still has a dependency on QtWebKit though, to catter for legacy webapps that use the 13.10 framework, as pointed out by Timo in the MR. I’d say all that’s needed is to thoroughly test existing webapps that still use QtWebKit. Is there a PPA we can use to test this new version? Olivier -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Updating QtWebKit to 5.2
(cc’ing David and Alex who may want to comment) On Fri, May 30, 2014 at 12:26 PM, Olivier Tilloy < olivier.til...@canonical.com> wrote: > > On Fri, May 30, 2014 at 8:29 AM, Dmitry Shachnev > wrote: > >> Hi all, >> >> I would very much like to update qtwebkit-opensource-src to version >> 5.2.0. It blocks syncs of other packages, like pyqt5, >> qtsensors-opensource-src and qtscript-opensource-src. It is also a >> prerequisite for updating Qt itself to version 5.3 (as qttools now >> depends on qtwebkit). >> >> According to Timo in >> >> https://code.launchpad.net/~mitya57/kubuntu-packaging/qtwebkit-merge-with-debian/+merge/216539 >> : >> >> > This looks it'd be great to have so I'm planning to build this for >> testing in addition to qtbase >> > and qtdeclarative when U opens, but we need to check with webapps >> people (= dbarth, >> > alex-abreu) on how they see this. >> > >> > I'm not clear on what's the schedule for full Oxide moving. In addition >> to touch also desktop >> > is currently including libqt5webkit5 in default install still (checked >> with seeded-in-ubuntu >> > qtwebkit-opensource-src). >> >> Does anybody know when it will be possible to upload this? >> >> I do not want to break Touch stuff, but I am already waiting for more >> than a month and don't want to wait more. >> > > As far as webbrowser-app is concerned, the transition to oxide is > complete. The webapp-container still has a dependency on QtWebKit though, > to catter for legacy webapps that use the 13.10 framework, as pointed out > by Timo in the MR. > > I’d say all that’s needed is to thoroughly test existing webapps that > still use QtWebKit. Is there a PPA we can use to test this new version? > -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
