Re: chromium-browser epoch bump for transitional package?
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. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: nodejs in groovy-proposed? (Re: +1 maintenance report)
On Tue, Aug 11, 2020 at 02:13:40PM -0700, Bryce Harrington wrote: > > The big problem I see right now is nodejs, which seems to have made a > > complete mess of the autopkgtests of its revdeps. I'd be interested to know > > if anyone is working on this and sees indications that it's tractable, or if > > we should just revert nodejs for now. > I worked on it quite a bit during my +1 maintenance shift a couple weeks > ago. It has indeed been a huge mess, but it has definitely gotten a lot > better. Looks to me like there's just three problems remaining for > nodejs itself: > a. The main remaining issue is that for three of the packages there is a > bug on pcc64el with SHA1 encryption[1], which osomon has been working > on, and found to be due to a compiler optimization error. He forwarded > it upstream[2] and yesterday upstream provided a patch to test[3]. So > this looks like it's on a path to be solved soon. > b. Another three packages appear to be hitting timeouts on autopkgtests, > for arm64 only. Their test histories look like they mostly fail with > scattered random passes. Maybe a flaky test? Maybe re-running it a few > times will resolve them? > c. node-clean-css is the only other failure. It occurs only on armhf > and only for a single test case. It doesn't print any details about > what the test case was or how it failed. > In addition to nodejs itself, many node-* packages need rebuilt or > retriggered. I did a bunch of these on my shift but we're getting > additional ones syncing from Debian. > So, nodejs feels reasonably close, and moving from nodejs 10 to 12 would > be a big improvement for users. Thanks for this information. It's good to know there's progress on nodejs; however, while it may be "reasonably close" taken in isolation, it's also the long pole for interconnected transitions that have been blocked for some time. So I've gone ahead and rolled nodejs back for now in order to disentangle the nodejs 12 transition from the icu, json-c, and boost transitions, and will restore the nodejs package to -proposed after that transition has completed. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Track clarification in UbuntuSeededSnaps Policy
Currently https://wiki.ubuntu.com/UbuntuSeededSnaps does not specify anything about tracks. Currently the status quo is to seed the default-track of the snap, aka "latest". Recently we have been approached by LXD upstream to use a different "LTS" track of the seeded lxd snap which has longer support timeframes and closer matches the timeframe of the Ubuntu Branch the seeded snap tracks. I would like to request additions to "Channel availability" section something along the lines of "The default track is used for seeding, which usually is called latest. Publishers may request seeding from a different track, if it better matches longevity of a given Ubuntu Series. Example: request to use lts track for Ubuntu 20.04 LTS release." -- Regards, Dimitri. -- 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?
Hi, On Wed, 12 Aug 2020 at 13:32, 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. lxd used epoch too, to ensure that deb2snap transitional package is always higher whichever backports are uploaded as debs into previous series. https://launchpad.net/ubuntu/+source/lxd So +1 from me. -- Regards, Dimitri. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
chromium-browser epoch bump for transitional package?
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. signature.asc Description: PGP signature -- 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 Tue, Aug 11, 2020 at 6:55 PM Bryce Harrington < bryce.harring...@canonical.com> wrote: > On Tue, Aug 04, 2020 at 09:53:26PM +1200, Michael Hudson-Doyle wrote: > > Hi all, > > > > I noticed golang-gopkg-square-go-jose.v2 times out on armhf, filed > > https://github.com/square/go-jose/issues/326. > > > > Then I looked at the icu transition. > > > > 0ad fails to build due to gcc-10, I found the fix for this upstream and > > backported it. > > > > I retried some ucto builds which appeared to have run before a build > > dependency had been built (maybe fallout from the build farm outage). And > > retried "frog" builds when these completed. > > > doxygen autopkgtests are failing because the json-c in proposed has moved > > its Doxyfile. > > > > doxygen's tests fail with the json-c in proposed: it builds the > > documentation for json-c in an autopkgtest but json-c has moved it's > > Doxyfile into a different directory. Easy to fix once json-c has > migrated. > > > > Cheers, > > mwh > > Could someone give a status update on the icu and json-c transitions? > I see they've been progressing daily, but curious since server team has > a few packages blocked from migrating. > Steve already answered the ICU question in a new thread and I've seen you participated there. To answer both, json-c seems complete except a chain of implicit dependencies json-c -> kamailio -> mongo-c-driver -> icu So json-c seems ready, but entangled with ICU right now. > Thanks, > Bryce > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel > -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Proposal: Enabling DMESG_RESTRICT for Groovy Onward
Hi Chris, [..] > Do you happen to know if there was a similar proposal discussed in > Debian? I don't believe this has been discussed in Debian. The only bugs I found was #570358 and #867747 which are for /var/log/dmesg only. Additionally, I found https://wiki.debian.org/NewInStretch, which mentions that "The dmesg command requires superuser privileges." I believe Debian might be interested in the change. For example, I started a Buster VM: $ head -1 /etc/os-release PRETTY_NAME="Debian GNU/Linux 10 (buster)" DMESG_RESTRICT is enabled, and my user is in group adm: $ grep -Rin "CONFIG_SECURITY_DMESG_RESTRICT" /boot/config-4.19.0-10-cloud-amd64 3130:CONFIG_SECURITY_DMESG_RESTRICT=y $ groups mruffell adm dip video plugdev Permissions for kern.log and syslog are for members of adm: $ ls -l /var/log/kern.log -rw-r- 1 root adm 39414 Aug 11 21:44 /var/log/kern.log $ ls -l /var/log/syslog -rw-r- 1 root adm 60744 Aug 11 21:56 /var/log/syslog I can read /var/log/kern.log and journalctl: $ head -2 /var/log/kern.log Aug 11 21:44:44 debian kernel: [0.00] Linux version 4.19.0-10-cloud-amd64 (debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.132-1 (2020-07-24) Aug 11 21:44:44 debian kernel: [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-10-cloud-amd64 root=UUID=fb69ad1f-43c0-40a4-8ec0-bb07f1175c82 ro console=tty0 console=ttyS0,115200 earlyprintk=ttyS0,115200 elevator=noop scsi_mod.use_blk_mq=Y $ journalctl -t kernel | head -3 -- Logs begin at Tue 2020-08-11 21:44:43 UTC, end at Tue 2020-08-11 22:12:30 UTC. -- Aug 11 21:44:43 debian kernel: Linux version 4.19.0-10-cloud-amd64 (debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.132-1 (2020-07-24) Aug 11 21:44:43 debian kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-10-cloud-amd64 root=UUID=fb69ad1f-43c0-40a4-8ec0-bb07f1175c82 ro console=tty0 console=ttyS0,115200 earlyprintk=ttyS0,115200 elevator=noop scsi_mod.use_blk_mq=Y And yet, I cannot access dmesg: $ dmesg dmesg: read kernel buffer failed: Operation not permitted $ ls -l /bin/dmesg -rwxr-xr-x 1 root root 84288 Jan 10 2019 /bin/dmesg Should I start a discussion on debian-devel, suggesting that Debian adopt the proposed changes to util-linux? If we get this accepted into Debian, Ubuntu could sync the package, and there would less delta to maintain going forward. [..] > This says: > > Depends: login (>= 1:4.5-1.1~), > + libcap2-bin (>= 1:2.32-1), > > Is there a specific reason for this specific libcap2-bin Version? There is no specific reason. The package only needs to depend on libcap2-bin for the setcap program only. The version I listed isn't completely arbitrary, it is the version found in Ubuntu 20.04. But the specific version check isn't necessary. It can be relaxed. Thanks, Matthew -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Communication Improvements/frustrations
It has been an intense time for multiple groups, thank you both for being willing to pull this frayed thread back into the tapestry. The many flavours of Ubuntu are an important part of our story, and occasionally it helps to remind ourselves of that. Free software is great because it enables people to pursue diverse interests and passions without having to get a central endorsement. Anybody can make a distro that explores the ideas they are interested in, without seeking Linus' blessing, or any company support. However, they then have the full burden of 'doing it right', with all the infrastructure and security and update work that entails. As a result, many of the more specialist distros suffer on base quality or security. Our flavours are a way of enabling people to express and share their interests in a different take on Linux, but benefit from all the shared effort that goes into the archive, at the (hopefully small) cost of coordinating in the archive and around releases. Perhaps it would be good to have a dashboard of things like queue length and wait time, together with a single 'status' page where current constraints could be expressed, if we don't already have that. We do also intend to appoint a dedicated person focused on community processes rather than Canonical processes; while they won't be expected to *do* this work, they would be a natural coordinator and able to provide more insight to all the groups that share the archive for their different goals. Mark signature.asc Description: OpenPGP digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
