Re: MIR question: upstream code in main pulled in code we have in universe

[Steve Langasek]

On Fri, Feb 11, 2022 at 01:43:31PM -0300, Andreas Hasenack wrote:
> On Fri, Feb 11, 2022 at 1:33 PM Steve Langasek
>  wrote:

> > On Fri, Feb 11, 2022 at 11:35:07AM -0300, Andreas Hasenack wrote:
> > > Hi, I have a question for the MIR (Main Inclusion Request) team members,

> > > New version of nfs-utils upstream (src:nfs-utils in main) pulled[1] in
> > > code (regex.c file) from another upstream project[2], for which we
> > > have a package in universe: src:libnfsidmap-regex

> > > Would this require another MIR review? I mean, in general, once a
> > > package is in main, we don't apply the MIR guidelines to it anymore,
> > > and they can usually change the code as the project sees fit.
> > > It just so happens this time we have this exact scenario where the
> > > code that was pulled already exists and is the sole purpose of
> > > another, universe, package.

> > > My options are basically:
> > > a) have src:nfs-utils build bin:libnfsidmap-regex and remove
> > > src:libnfsidmap-regex from the archive
> > > b) build src:nfs-utils without producing bin:libnfsidmap-regex, and
> > > keep building src:libnfsidmap-regex from universe as usual

> > > Option (b) will incurr in delta with debian. I believe[3] Debian will
> > > eventually remove/obsolete src:libnfsidmap-regex

> > > 1. 
> > > http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;h=940caffdfb9953a2ccfecec81664e4a179753461
> > > 2. https://github.com/isginf/libnfsidmap-regex
> > > 3. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925022#20

> > I think you should submit it for an additional MIR review if and only if
> > there is reason to consider the new library security-sensitive.  (If it's a
> > library that will be used by one of the NFS daemons, that's a good reason to
> > think it's security-sensitive.)

> Yeah, it's an libnfsidmap plugin that applies regular expressions to
> NFSv4 usernames and group names that come over the wire in the form
> user@DOMAIN and group@DOMAIN.

> What if I keep bin:libnfsidmap-regex, built from the new
> src:nfs-utils, in universe? With a remark in d/control that it should
> not be promoted to main without a specific new MIR?

I think that's also acceptable.

-- 
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

/boot disk partition size

[Erich Eickmeyer]

Hi all,

Many of you know me as the leader of Ubuntu Studio and member of the Ubuntu 
Community Council. However, in my day job, I'm the User Experience and 
Packaging director for the Kubuntu Focus project.

For those of you unfamiliar, Kubuntu Focus is a line of laptop computers that 
come with Kubuntu preinstalled. This makes us an OEM for Kubuntu, and Ubuntu 
by extension. 

With that in mind, I work for Michael Mikowski in this regard. He's a highly 
experienced developer and system administrator, but is not currently an Ubuntu 
member or Ubuntu developer and cannot post on this list, which is why I'm 
acting as an intermediary with both my Ubuntu developer and Kubuntu Focus hats 
on.

With that in mind, please read the forwarded message below to understand the 
context for this. Please respond to this message not only to the mailing list, 
but to mmikow...@kfocus.org as well.

Thanks,
Erich
-
Erich Eickmeyer
Project Leader - Ubuntu Studio
Member - Ubuntu Community Council

-- Forwarded message -
From: Michael Mikowski 
Date: Thu, Feb 10, 2022, 18:38
Subject: /boot disk partition size
To: 


Hi Everyone:

Members of the Ubuntu Foundations Team asked me to clarify the issue with /
boot. You can see the bugs filed at https://launchpad.net/bugs/1959971 and
https://launchpad.net/bugs/1960089. *Personal Background:*
I currently lead the Kubuntu Focus  engineering
efforts, and have been a professional product engineer specializing in
mission-critical HP/HA/HV systems for decades. You can see a overview of my
experience at https://michaelmikowski.com.

*My Assessments:*

*0. This is a low-cost, high-return proposal.* People have pushed back
against increasing the /boot partition, but I find most of the reasoning
does not consider the true impact of a small /boot partition to the
complete product.

*1. The cost to provide the space needed is minimal for almost all FDE
systems. *So why not just do it? Of course, there is more work to be done
for the rest of the product (guide users on kernel selection; improve the
kernel cleaning logic), but this is an important component that is required
in any complete solution. It would provide substantial relief to many users
immediately.

*2. An overfull /boot partition is catastrophic for many users.* Many
cannot recover their system because they don't have a rescue disk or
knowledge of ext4, chroot, LUKS, lvm, cryptesetup, package management, and
more. These people either reload the OS or give up.

*3. This happens frequently, even when everything works as designed*, and
even when just using a single kernel flavor. While on IRC yesterday
discussing this, 3 unsolicited individuals stepped in to comment about how
this is needed. And those are advanced developers who know better. Search
for 'ubuntu full /boot partition' and check out how frequently this
continues to occur.

*4. There are many use cases where multiple kernel flavors will occur*,
such as when the users switches from HWE to OEM to address hardware issues,
or they install lowlatency for studio work. When this happens, the current
size boot partition is highly likely to fill. This can corrupt the system
and require a rescue disk for recovery.

Check out the DFMEA which is used to assess the severity of a failure mode:
https://bugs.launchpad.net/ubuntu/+source/partman-auto/+bug/1959971/comments/7

Finally, I assure you the calculations for kernel boot-file-set sizes (180M
with Nvidia GPU) are correct for 20.04, and will be correct for 22.04
unless the compression technique has been changed. It seems perfectly
reasonable to expect this size to grow to 200M or more over the next 2
years. Also, the headroom + safety factor specified (10 kernel file-sets
total) is reasonable when you consider that systems that reboot less
frequently will accumulate kernels and that a single upgrade can install
multiple additional kernel images.

Sincerely, Mike


signature.asc
Description: This is a digitally signed message part.
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: MIR question: upstream code in main pulled in code we have in universe

[Andreas Hasenack]

Hi,

On Fri, Feb 11, 2022 at 1:33 PM Steve Langasek
 wrote:
>
> On Fri, Feb 11, 2022 at 11:35:07AM -0300, Andreas Hasenack wrote:
> > Hi, I have a question for the MIR (Main Inclusion Request) team members,
>
> > New version of nfs-utils upstream (src:nfs-utils in main) pulled[1] in
> > code (regex.c file) from another upstream project[2], for which we
> > have a package in universe: src:libnfsidmap-regex
>
> > Would this require another MIR review? I mean, in general, once a
> > package is in main, we don't apply the MIR guidelines to it anymore,
> > and they can usually change the code as the project sees fit.
> > It just so happens this time we have this exact scenario where the
> > code that was pulled already exists and is the sole purpose of
> > another, universe, package.
>
> > My options are basically:
> > a) have src:nfs-utils build bin:libnfsidmap-regex and remove
> > src:libnfsidmap-regex from the archive
> > b) build src:nfs-utils without producing bin:libnfsidmap-regex, and
> > keep building src:libnfsidmap-regex from universe as usual
>
> > Option (b) will incurr in delta with debian. I believe[3] Debian will
> > eventually remove/obsolete src:libnfsidmap-regex
>
> > 1. 
> > http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;h=940caffdfb9953a2ccfecec81664e4a179753461
> > 2. https://github.com/isginf/libnfsidmap-regex
> > 3. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925022#20
>
> I think you should submit it for an additional MIR review if and only if
> there is reason to consider the new library security-sensitive.  (If it's a
> library that will be used by one of the NFS daemons, that's a good reason to
> think it's security-sensitive.)

Yeah, it's an libnfsidmap plugin that applies regular expressions to
NFSv4 usernames and group names that come over the wire in the form
user@DOMAIN and group@DOMAIN.

What if I keep bin:libnfsidmap-regex, built from the new
src:nfs-utils, in universe? With a remark in d/control that it should
not be promoted to main without a specific new MIR?

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: MIR question: upstream code in main pulled in code we have in universe

[Steve Langasek]

On Fri, Feb 11, 2022 at 11:35:07AM -0300, Andreas Hasenack wrote:
> Hi, I have a question for the MIR (Main Inclusion Request) team members,

> New version of nfs-utils upstream (src:nfs-utils in main) pulled[1] in
> code (regex.c file) from another upstream project[2], for which we
> have a package in universe: src:libnfsidmap-regex

> Would this require another MIR review? I mean, in general, once a
> package is in main, we don't apply the MIR guidelines to it anymore,
> and they can usually change the code as the project sees fit.
> It just so happens this time we have this exact scenario where the
> code that was pulled already exists and is the sole purpose of
> another, universe, package.

> My options are basically:
> a) have src:nfs-utils build bin:libnfsidmap-regex and remove
> src:libnfsidmap-regex from the archive
> b) build src:nfs-utils without producing bin:libnfsidmap-regex, and
> keep building src:libnfsidmap-regex from universe as usual

> Option (b) will incurr in delta with debian. I believe[3] Debian will
> eventually remove/obsolete src:libnfsidmap-regex

> 1. 
> http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;h=940caffdfb9953a2ccfecec81664e4a179753461
> 2. https://github.com/isginf/libnfsidmap-regex
> 3. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925022#20

I think you should submit it for an additional MIR review if and only if
there is reason to consider the new library security-sensitive.  (If it's a
library that will be used by one of the NFS daemons, that's a good reason to
think it's security-sensitive.)

-- 
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

MIR question: upstream code in main pulled in code we have in universe

[Andreas Hasenack]

Hi, I have a question for the MIR (Main Inclusion Request) team members,

New version of nfs-utils upstream (src:nfs-utils in main) pulled[1] in
code (regex.c file) from another upstream project[2], for which we
have a package in universe: src:libnfsidmap-regex

Would this require another MIR review? I mean, in general, once a
package is in main, we don't apply the MIR guidelines to it anymore,
and they can usually change the code as the project sees fit.
It just so happens this time we have this exact scenario where the
code that was pulled already exists and is the sole purpose of
another, universe, package.

My options are basically:
a) have src:nfs-utils build bin:libnfsidmap-regex and remove
src:libnfsidmap-regex from the archive
b) build src:nfs-utils without producing bin:libnfsidmap-regex, and
keep building src:libnfsidmap-regex from universe as usual

Option (b) will incurr in delta with debian. I believe[3] Debian will
eventually remove/obsolete src:libnfsidmap-regex

1. 
http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;h=940caffdfb9953a2ccfecec81664e4a179753461
2. https://github.com/isginf/libnfsidmap-regex
3. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925022#20

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel