Re: Proper way to handle britney hints
On Mon, Aug 6, 2018 at 7:01 PM Steve Langasek wrote: > > On Mon, Aug 06, 2018 at 09:39:27AM -0300, Andreas Hasenack wrote: > > > I would like to know how to properly handle updates to the so called > > "britney hints", which controls how DEP8 test failures are handled in > > migrations. Particularly for the development release. > > > I uploaded https://launchpad.net/ubuntu/+source/ocfs2-tools/1.8.5-5ubuntu1 > > on Jul 31st, and it has a known failure[1][2] on s390x, for which I > > proposed this branch[2]. I also pinged in #ubuntu-release several > > times after that. > > > It seems this communication got lost somehow. Except I already got two > > emails from some bot telling me my package hasn't migrated and I > > should do something about it, so that part is working. > > > So here is me doing something about it :) > > > 1. https://github.com/markfasheh/ocfs2-tools/issues/22 > > 2. https://bugs.launchpad.net/ubuntu/+source/ocfs2-tools/+bug/1745155 > > 3. > > https://code.launchpad.net/~ahasenack/britney/ocfs2-tools-hints-1.8.5-5ubuntu1/+merge/351928 > > It seems your MP has the review requested from a team that is not the owner > of the target branch, do you know why that is? (~ubuntu-archive vs. > ~ubuntu-release) No, I just made the proposal and accepted the default reviewer, i.e., I left the "reviewer" box empty. > I don't guarantee that this would have resulted in a better response, but > it's something to look at. I'll be sure to pay attention to that next time. > As for IRC pings, I don't know why your particular pings were missed, but I > personally only highlight on my own IRC nick on that channel. I understand > it's not the most efficient for requesters and can be frustrating, but don't > hesitate to highlight me by name if you need something looked at. Right, I don't like to ping people directly because that doesn't "spread the load", and I've seen others just make such requests in the channel to no one in particular, so that's the avenue I followed. So, MP with the correct reviewer group, plus generic ping, and if nothing happens after a day or two, ping someone directly. > > I've followed through now on that particular MP. Thanks, much appreciated -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Proper way to handle britney hints
On Mon, Aug 06, 2018 at 09:39:27AM -0300, Andreas Hasenack wrote: > I would like to know how to properly handle updates to the so called > "britney hints", which controls how DEP8 test failures are handled in > migrations. Particularly for the development release. > I uploaded https://launchpad.net/ubuntu/+source/ocfs2-tools/1.8.5-5ubuntu1 > on Jul 31st, and it has a known failure[1][2] on s390x, for which I > proposed this branch[2]. I also pinged in #ubuntu-release several > times after that. > It seems this communication got lost somehow. Except I already got two > emails from some bot telling me my package hasn't migrated and I > should do something about it, so that part is working. > So here is me doing something about it :) > 1. https://github.com/markfasheh/ocfs2-tools/issues/22 > 2. https://bugs.launchpad.net/ubuntu/+source/ocfs2-tools/+bug/1745155 > 3. > https://code.launchpad.net/~ahasenack/britney/ocfs2-tools-hints-1.8.5-5ubuntu1/+merge/351928 It seems your MP has the review requested from a team that is not the owner of the target branch, do you know why that is? (~ubuntu-archive vs. ~ubuntu-release) I don't guarantee that this would have resulted in a better response, but it's something to look at. As for IRC pings, I don't know why your particular pings were missed, but I personally only highlight on my own IRC nick on that channel. I understand it's not the most efficient for requesters and can be frustrating, but don't hesitate to highlight me by name if you need something looked at. I've followed through now on that particular MP. Thanks, -- 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: RFC: baseline requirements for Ubuntu rootfs: xattrs and fscaps
Hi John, On Mon, Aug 06, 2018 at 10:09:53PM +0100, John Lenton wrote: > On Mon, 6 Aug 2018 at 21:16, Steve Langasek wrote: > > I think it's exceedingly unlikely that anyone is going to unpack, and > > subsequently boot, an Ubuntu root tarball on a filesystem that doesn't > > support xattrs. All the filesystems that Ubuntu supports out of the box as > > rootfs (in terms of installers, and filesystem tools preinstalled) support > > xattrs. > while this is strictly true, 'snap pack' and 'snapcraft pack' > currently disable xattrs, and the store will not approve snaps that > are built with xattrs. Thanks, that's a useful data point. Do you think it is a practical concern for snaps if an Ubuntu rootfs uses fscaps? Is this an argument against allowing fscaps in Ubuntu, or should it just be a matter for snapcraft to warn/error about on creation, guiding users to using setuid instead? As a worked example: the core snap does ship /bin/ping, which is currently setuid-root in Ubuntu but would move to fscaps in this proposal. (The core snap does not include mtr-tiny.) What do you believe is the correct outcome here for /bin/ping in a future ubuntu core 20 snap? -- 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: RFC: baseline requirements for Ubuntu rootfs: xattrs and fscaps
On Mon, Aug 06, 2018 at 02:23:30PM +0100, Robie Basak wrote: > 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: > [...] > > - Users who are unpacking root tarballs need to take care to pass > >--xattrs-include=* to tar. > I think it's worth pointing out that users unpacking root tarballs to > filesystems that don't support xattrs will be broken. I'm not sure how > widespread this is, but I'm thinking of the use of cloud images and the > Ubuntu Base image. In the interests of moving forward, perhaps it makes > sense to make this breaking change in Ubuntu. I think it's exceedingly unlikely that anyone is going to unpack, and subsequently boot, an Ubuntu root tarball on a filesystem that doesn't support xattrs. All the filesystems that Ubuntu supports out of the box as rootfs (in terms of installers, and filesystem tools preinstalled) support xattrs. > Would it be an idea to make it such that booting an Ubuntu system on a > filesystem that doesn't support xattrs deliberately fails early, to > avoid users being hit with subtle bugs later? The error could include > instructions on disabling the check for users who want to proceed > anyway. IMHO that would be overengineering for a corner case. -- 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: 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: [...] > - Users who are unpacking root tarballs need to take care to pass >--xattrs-include=* to tar. I think it's worth pointing out that users unpacking root tarballs to filesystems that don't support xattrs will be broken. I'm not sure how widespread this is, but I'm thinking of the use of cloud images and the Ubuntu Base image. In the interests of moving forward, perhaps it makes sense to make this breaking change in Ubuntu. Would it be an idea to make it such that booting an Ubuntu system on a filesystem that doesn't support xattrs deliberately fails early, to avoid users being hit with subtle bugs later? The error could include instructions on disabling the check for users who want to proceed anyway. 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
Proper way to handle britney hints
Hi, I would like to know how to properly handle updates to the so called "britney hints", which controls how DEP8 test failures are handled in migrations. Particularly for the development release. I uploaded https://launchpad.net/ubuntu/+source/ocfs2-tools/1.8.5-5ubuntu1 on Jul 31st, and it has a known failure[1][2] on s390x, for which I proposed this branch[2]. I also pinged in #ubuntu-release several times after that. It seems this communication got lost somehow. Except I already got two emails from some bot telling me my package hasn't migrated and I should do something about it, so that part is working. So here is me doing something about it :) 1. https://github.com/markfasheh/ocfs2-tools/issues/22 2. https://bugs.launchpad.net/ubuntu/+source/ocfs2-tools/+bug/1745155 3. https://code.launchpad.net/~ahasenack/britney/ocfs2-tools-hints-1.8.5-5ubuntu1/+merge/351928 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
