Re: New tzdata release for ubuntu 20.04 lts (and higher)

[Dimitri John Ledkov]

tzdata should be updated in legacy releases via Ubuntu Pro, which you
should be able to gain access to via ubuntu.com/pro

On Mon, 19 Feb 2024, 17:19 Dauren Sarsenov,  wrote:

> Hi, guys.
>
> Good news, I can see that an updated version of tzdata has been released
> for Ubuntu 24.04 LTS.
>
> Can you suggest, how can i backport it to Ubuntu 18.04, 16.04 (as they are
> retired, i guess they will never see the update otherwise)?
>
>
>
> Best
>
> Dauren
>
> > On 8 Feb 2024, at 16:45, Adrien Nader  wrote:
> >
> > Hi,
> >
> > On Sat, Feb 03, 2024, Dauren Sarsenov wrote:
> >> Hi, guys.
> >>
> >> I wonder, how much time does it usually take to release an update
> version of tzdata package? Asking, because there is a new upstream build (
> https://www.iana.org/time-zones), and rather critical one to us, who live
> in Kazakhstan. The clock is to be moved 1 hour back on the 1st of March
> 2024. The new build of tzdata contains the appropriate rule, thus it is
> highly anticipated currently.
> >
> > On the Ubuntu side, we are aware of the update but the person usually
> > doing the updates has not been able to do it. This is something that we
> > are planning to address in the next two weeks (regardless of their
> > availability) although I cannot fully guarantee it at the moment.
> >
> > Best,
> >
> > --
> > Adrien
>
>
> --
> 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
>
-- 
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 for Update: NVIDIA Driver Version 535.146.02 for APT

[Dimitri John Ledkov]

Hi,

This version of this driver has been available in the proposed pocket
since 2023-12-15 and is undergoing testing. It will be released to
updates once regression and certification testing is completed. Note
we do not release routine updates like these over the winter holidays
period which was between 16th of December and today.

On Sun, 31 Dec 2023 at 17:29, Владислав  wrote:
>
> Dear Ubuntu APT Package Manager Maintainers,
>
> I hope this message finds you well. I am writing to bring to your attention 
> the recent release of the NVIDIA display driver version 535.146.02, 
> specifically designed for Linux x64 (AMD64/EM64T) systems on December 7, 2023.
>
> As an Ubuntu user and part of the community that greatly values the seamless 
> functionality and performance of our systems, I wish to highlight the 
> importance of updating the NVIDIA package within the Ubuntu APT repositories 
> to include this latest driver version.
>
> The advancements and improvements made in the latest NVIDIA driver iteration, 
> version 535.146.02, offer enhanced features, stability, and compatibility 
> with a wide range of hardware configurations and the most important they 
> fixed some bugs related to OS that uses several GPUs, so I had this error and 
> the driver version (535.129.03) didn't work well when system has several 
> GPUs. These updates are crucial for optimizing the performance and 
> compatibility of NVIDIA GPUs with Ubuntu systems, ensuring a better user 
> experience for all Ubuntu users who rely on NVIDIA graphics hardware.
>
> Looking forward to seeing the latest NVIDIA driver version integrated into 
> the Ubuntu repositories soon.
>
> Best regards,
>
> Vladyslav Matsapura.
>
> --
> 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



-- 
Dimitri

Sent from Ubuntu Pro
https://ubuntu.com/pro

-- 
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: Choice of the openssl version for 23.10 and 24.04

[Dimitri John Ledkov]

On Mon, 4 Dec 2023 at 12:34, Adrien Nader  wrote:
>
> (stripping the quotes a bit)
>
> On Mon, Dec 04, 2023, Dimitri John Ledkov wrote:
> > On Mon, 4 Dec 2023 at 09:28, Adrien Nader  wrote:
> > > The issue is that we do not know when will be the next openssl LTS. We
> > That's irrelevant. Once Ubuntu release goes stable, we no longer apply
> > full upstream point releases, and create our own stream of security
> > and stable fixes anyway.
> > Our timelines of support are also longer than either shorter or longer
> > upstream support timelines.
>
> The point is that security updates require work and using a version that
> no other distribution uses (which will always be the case unless other
> distribution release dates align with Ubuntu's) prevents sharing the
> work with other distributions. This was stated earlier (months ago) in
> this thread. I don't know how that played out in hindsight. That would
> be an interesting thing to know.
>
> Even if we're not on the same point version as other distributions,
> there is still a lot of common things, especially for typical security
> patches, and lots of testing in common. I don't think the patches are
> very difficult to port across versions (except the ones which porting is
> horribly painful) but QA and verification are another matter. Keep in
> mind that 3.0 was a big release with many architectural changes and this
> has continued in 3.1 and 3.2. There are certainly fewer and fewer
> changes but I don't think I would call these changes uncommon yet.
>
> Finally, Ubuntu is not the only distribution with longer support than
> openssl's five years for LTS: there can still be cross-distro
> cooperation after these years, and it will actually be even more
> valuable.
>
> > > can safely bet there will be one before 26.04 and update to the most
> > > recent version for 24.10 (since by 26.04, the current LTS won't be
> > > supported anymore). However we can't really bet there will be one by
> > > 24.04 and even if there were, there probably wouldn't be a new one in
> > > time by 26.04.
> > >
> > > What you are asking for is equivalent to not using openssl LTS releases
> > > for Ubuntu LTS releases.
> >
> > Yes.
> >
> > > There are many more non-LTS releases so we're
> > > more likely to end up with a non-LTS version.
> > >
> > > Openssl time-based releases are very very recent.
> >
> > We did ship the first KDE time-based release when it came out for the
> > first time.
>
> KDE, especially in Ubuntu, is far less risky than openssl. It is also
> updated far more easily.
>
> I've been trying to make an SRU for openssl for several months now and
> it hasn't landed yet. I'm not blaming anyone here: there are tons of
> reasons for that (including the fact that I don't have the bandwidth to
> re-spin something at the moment).
>
> The fact is that today we're not able to update openssl for anything
> except security updates. In other words, no matter what the openssl
> maintainer puts in a release, that maintainer won't have anything to do
> with it after the release: only the security team will. That makes me
> completely uncomfortable with using a release without some kind of
> agreement with the security team. Using the most recent version would
> make my life easier but I don't think it's the right trade-off here.
>
> By the way, I don't know how that would play with FIPS: I'm not sure it
> would be manageable.
>
> > > This was announced
> > > late August and only one version was released under this model so far.
> > > It wasn't even on time. The delay was fairly small, especially for a
> > > first version using this model (and a change mid-cycle). I think they
> > > need a bit more time. Will they be late again? Will they continue this
> > > scheme? What else? I don't expect openssl upstream can answer these;
> > > they don't have enough hindsight yet.
> > >
> > > We talked about creating a new "openssl" package that is whatever the
> > > most recent version is (in universe, and probably with no ESM-guarantee
> > > attached somehow). This might need a bit of fiddling with packaging
> > > though and in any case, I've had absolutely no time to do that so far.
> > >
> > > Would such a package fit the needs you see?
> >
> > Only one version, the latest openssl, in every Ubuntu release, going 
> > forward.
> >
> > Shipping two openssl in the archive is extremely difficult and ends up
> > being unusable. Devel packages previously have not been coinstallable
>

Re: Choice of the openssl version for 23.10 and 24.04

[Dimitri John Ledkov]

On Mon, 4 Dec 2023 at 12:34, Adrien Nader  wrote:
>
> (stripping the quotes a bit)
>
> On Mon, Dec 04, 2023, Dimitri John Ledkov wrote:
> > On Mon, 4 Dec 2023 at 09:28, Adrien Nader  wrote:
> > > The issue is that we do not know when will be the next openssl LTS. We
> > That's irrelevant. Once Ubuntu release goes stable, we no longer apply
> > full upstream point releases, and create our own stream of security
> > and stable fixes anyway.
> > Our timelines of support are also longer than either shorter or longer
> > upstream support timelines.
>
> The point is that security updates require work and using a version that
> no other distribution uses (which will always be the case unless other
> distribution release dates align with Ubuntu's) prevents sharing the
> work with other distributions. This was stated earlier (months ago) in
> this thread. I don't know how that played out in hindsight. That would
> be an interesting thing to know.
>
> Even if we're not on the same point version as other distributions,
> there is still a lot of common things, especially for typical security
> patches, and lots of testing in common. I don't think the patches are
> very difficult to port across versions (except the ones which porting is
> horribly painful) but QA and verification are another matter. Keep in
> mind that 3.0 was a big release with many architectural changes and this
> has continued in 3.1 and 3.2. There are certainly fewer and fewer
> changes but I don't think I would call these changes uncommon yet.
>
> Finally, Ubuntu is not the only distribution with longer support than
> openssl's five years for LTS: there can still be cross-distro
> cooperation after these years, and it will actually be even more
> valuable.
>
> > > can safely bet there will be one before 26.04 and update to the most
> > > recent version for 24.10 (since by 26.04, the current LTS won't be
> > > supported anymore). However we can't really bet there will be one by
> > > 24.04 and even if there were, there probably wouldn't be a new one in
> > > time by 26.04.
> > >
> > > What you are asking for is equivalent to not using openssl LTS releases
> > > for Ubuntu LTS releases.
> >
> > Yes.
> >
> > > There are many more non-LTS releases so we're
> > > more likely to end up with a non-LTS version.
> > >
> > > Openssl time-based releases are very very recent.
> >
> > We did ship the first KDE time-based release when it came out for the
> > first time.
>
> KDE, especially in Ubuntu, is far less risky than openssl. It is also
> updated far more easily.
>
> I've been trying to make an SRU for openssl for several months now and
> it hasn't landed yet. I'm not blaming anyone here: there are tons of
> reasons for that (including the fact that I don't have the bandwidth to
> re-spin something at the moment).
>
> The fact is that today we're not able to update openssl for anything
> except security updates. In other words, no matter what the openssl
> maintainer puts in a release, that maintainer won't have anything to do
> with it after the release: only the security team will. That makes me
> completely uncomfortable with using a release without some kind of
> agreement with the security team. Using the most recent version would
> make my life easier but I don't think it's the right trade-off here.
>
> By the way, I don't know how that would play with FIPS: I'm not sure it
> would be manageable.

We do our own FIPS certification, and we do it based on whichever
version we ship, with staff & cert team working on that. We have
certified OpenSSL as needed for our purposes, irrespective of the
upstream FIPS efforts, due to the ways we make api & abi compatible
drop-in replacement without any need to change any runtime configs.

So far FIPS team will certify whatever noble will ship.

>
> > > This was announced
> > > late August and only one version was released under this model so far.
> > > It wasn't even on time. The delay was fairly small, especially for a
> > > first version using this model (and a change mid-cycle). I think they
> > > need a bit more time. Will they be late again? Will they continue this
> > > scheme? What else? I don't expect openssl upstream can answer these;
> > > they don't have enough hindsight yet.
> > >
> > > We talked about creating a new "openssl" package that is whatever the
> > > most recent version is (in universe, and probably with no ESM-guarantee
> > > attached somehow). This might need a bit of fiddling with packaging
> > > though and in any case, I've had absolu

Re: Choice of the openssl version for 23.10 and 24.04

[Dimitri John Ledkov]

On Mon, 4 Dec 2023 at 09:28, Adrien Nader  wrote:
>
> On Mon, Dec 04, 2023, Dimitri John Ledkov wrote:
> > Hi,
> >
> > On Fri, 20 Oct 2023 at 15:35, Adrien Nader  wrote:
> > >
> > > On Fri, Oct 20, 2023, Adrien Nader wrote:
> > > > Hi,
> > > >
> > > > A few weeks ago, openssl maintainers announced moving to a time-based
> > > > release (April and October):
> > > >
> > > > https://www.openssl.org/blog/blog/2023/09/29/OpenSSL-Update-ICMC23/
> > > >
> > > > > Key takeaway 3 : Time Based Release Policy
> > > > > We’re transitioning to time-based releases. This shift ensures
> > > > > predictability, allowing our users and developers to plan better and
> > > > > benefit from timely updates. The releases will be scheduled every
> > > > > April and October.
> > > >
> > > > Based on this and the openssl 3.0 release date, I'd expect a new LTS
> > > > version to be released (almost) in time for 26.04 but not for 24.04.
> > > >
> > > > *IF* an openssl LTS release is out in April 26.04, we might want to
> > > > track the corresponding openssl git branch during the 26.04 release in
> > > > order to be able to ship it. This is more than two years away however
> > > > and a lot can happen until then. I don't have a crystal ball
> > > > unfortunately. In any case, we'll know if the planned and the actual
> > > > release cadence and calendar match.
> > >
> > > Dimitri asked me for some more details so I dug a bit more. It's
> > > actually better explained in a better blog post from late August:
> > >
> > > https://www.openssl.org/blog/blog/2023/08/27/steps-forward
> > >
> > > > We’re also shifting how we release the OpenSSL library. We’ve adopted
> > > > a time-based release policy, with releases every April and October.
> > > > After our 3.2 release in October, our 3.3 release in April next year
> > > > will be our first time-based release, marking our initial venture into
> > > > this approach.
> > >
> > > And the release policy has been updated too:
> > >
> > > https://www.openssl.org/policies/general/release-policy.html
> > >
> > > > Planning: Continuous process, provides input to the Release Definition 
> > > > phase.
> > > > Release Definition: Defines release backlog, lasts up to 4 weeks.
> > > > Development: Execution of the release backlog, spans from 20 to 24 
> > > > weeks.
> > > > Release: Addressing issues discovered by the community in pre-releases. 
> > > > Up to 6 weeks.
> > > > Support: A support phase.
> > >
> > > If they follow their plan, we'd therefore have pre-release versions
> > > several weeks before Ubuntu releases. Of course, feature freeze
> > > concerns apply if the pre-release isn't out in time.
> > >
> > > That's all I've seen so far (OK, I didn't dig that much). We'll see very
> > > soon how that turns out in practice for the 3.2 release.
> >
> > With every other major piece of our dependencies, we have committed to
> > picking up regular time based releases which fit our schedule.
> > This includes things like GNOME, KDE, OpenStack, GCC.
> > I think we should commit to picking up the latest OpenSSL for every
> > Ubuntu release going forward.
> > 3.2 has been released, albeit in late November, and we should show
> > good will and encourage OpenSSL to stick to their new time based
> > releases.
> >
> > Can we please start the upgrade of OpenSSL to 3.2?
> >
> > And then if OpenSSL 3.3 is released in early April, pick that up as
> > well for 24.04. If the new cadence for 3.3 means May, pick it up for
> > the 24.10 instead.
>
> The issue is that we do not know when will be the next openssl LTS. We

That's irrelevant. Once Ubuntu release goes stable, we no longer apply
full upstream point releases, and create our own stream of security
and stable fixes anyway.
Our timelines of support are also longer than either shorter or longer
upstream support timelines.

> can safely bet there will be one before 26.04 and update to the most
> recent version for 24.10 (since by 26.04, the current LTS won't be
> supported anymore). However we can't really bet there will be one by
> 24.04 and even if there were, there probably wouldn't be a new one in
> time by 26.04.
>
> What you are asking for is equivalent to not using openssl LTS releases
> for Ubuntu LTS 

Re: Choice of the openssl version for 23.10 and 24.04

[Dimitri John Ledkov]

Hi,

On Fri, 20 Oct 2023 at 15:35, Adrien Nader  wrote:
>
> On Fri, Oct 20, 2023, Adrien Nader wrote:
> > Hi,
> >
> > A few weeks ago, openssl maintainers announced moving to a time-based
> > release (April and October):
> >
> > https://www.openssl.org/blog/blog/2023/09/29/OpenSSL-Update-ICMC23/
> >
> > > Key takeaway 3 : Time Based Release Policy
> > > We’re transitioning to time-based releases. This shift ensures
> > > predictability, allowing our users and developers to plan better and
> > > benefit from timely updates. The releases will be scheduled every
> > > April and October.
> >
> > Based on this and the openssl 3.0 release date, I'd expect a new LTS
> > version to be released (almost) in time for 26.04 but not for 24.04.
> >
> > *IF* an openssl LTS release is out in April 26.04, we might want to
> > track the corresponding openssl git branch during the 26.04 release in
> > order to be able to ship it. This is more than two years away however
> > and a lot can happen until then. I don't have a crystal ball
> > unfortunately. In any case, we'll know if the planned and the actual
> > release cadence and calendar match.
>
> Dimitri asked me for some more details so I dug a bit more. It's
> actually better explained in a better blog post from late August:
>
> https://www.openssl.org/blog/blog/2023/08/27/steps-forward
>
> > We’re also shifting how we release the OpenSSL library. We’ve adopted
> > a time-based release policy, with releases every April and October.
> > After our 3.2 release in October, our 3.3 release in April next year
> > will be our first time-based release, marking our initial venture into
> > this approach.
>
> And the release policy has been updated too:
>
> https://www.openssl.org/policies/general/release-policy.html
>
> > Planning: Continuous process, provides input to the Release Definition 
> > phase.
> > Release Definition: Defines release backlog, lasts up to 4 weeks.
> > Development: Execution of the release backlog, spans from 20 to 24 weeks.
> > Release: Addressing issues discovered by the community in pre-releases. Up 
> > to 6 weeks.
> > Support: A support phase.
>
> If they follow their plan, we'd therefore have pre-release versions
> several weeks before Ubuntu releases. Of course, feature freeze
> concerns apply if the pre-release isn't out in time.
>
> That's all I've seen so far (OK, I didn't dig that much). We'll see very
> soon how that turns out in practice for the 3.2 release.

With every other major piece of our dependencies, we have committed to
picking up regular time based releases which fit our schedule.
This includes things like GNOME, KDE, OpenStack, GCC.
I think we should commit to picking up the latest OpenSSL for every
Ubuntu release going forward.
3.2 has been released, albeit in late November, and we should show
good will and encourage OpenSSL to stick to their new time based
releases.

Can we please start the upgrade of OpenSSL to 3.2?

And then if OpenSSL 3.3 is released in early April, pick that up as
well for 24.04. If the new cadence for 3.3 means May, pick it up for
the 24.10 instead.

-- 
Dimitri

Sent from Ubuntu Pro
https://ubuntu.com/pro

-- 
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: Intermittent superblock checksum mismatch during resize2fs

[Dimitri John Ledkov]

This was causing us headaches like since forever. Our reproducers were very
intermittent to catch it. I think we might want to backport this everywhere
we can.

On Thu, 5 Oct 2023, 17:50 Krister Johansen,  wrote:

> Hi,
> My team runs Ubuntu 20.04 on EC2.  We use the cloud images that
> Canonical and AWS publish for Ubuntu as our base image.  As part of
> the first boot of one of these images, cloud-init runs resiz2fs in order
> to make the root filesystem match the size of the root volume on which the
> instance is provisioned.
>
> A few times a week, this would fail for us, which results in instances
> that have an unexpectedly small root filesystem.  We were able to build
> a reproducer for the problem, debug it, and get it fixed upstream.
> There's a patch in the main branch of e2fsprogs with the fix now.
>
> We've had to fork the Ubuntu version of e2fsprogs to carry this patch,
> but from our analysis it ought to impact (potentially) any customer
> running on EC2.  Would Ubuntu be willing to backport this patch to the
> versions for which they build EC2 AMIs?  (We're specifically interested
> in any LTS Ubuntu releases).
>
> I logged a ticket for this on launchpad here (it includes the
> reproducer):
>
> https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/2036467
>
> The patch itself is a 2-line change:
>
>
> https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/commit/?id=43a498e938887956f393b5e45ea6ac79cc5f4b84
>
> The thread where this was discussed with the upstream maintainer is
> here:
>
> https://lore.kernel.org/linux-ext4/20230609042239.ga1436...@mit.edu/
>
> Thanks very much,
>
> -K
>
> --
> 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
>
-- 
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: Open-SSH server

[Dimitri John Ledkov]

On Sat, 10 Jun 2023, 19:39 Matthew Wilson, 
wrote:

> Hi there,
>
>
>
> Do you have an update as to when the repository for Ubuntu 22.04.2 package
> Open-SSH will be upgraded from 8.9 to 9.3 to patch the security issues as
> it means our server is currently non-compliant.
>

Non complaint with what exactly? 9.3 is available in the current
development release mantic. Note that 8.9 and 9.3 are major new upstream
releases of openssh with new features and bugfixes. And are not indication
of security vulnerabilities. When vulnerabilities arise, Ubuntu issues USN
and a distribution patch update addressing vulnerability alone without
upgrading to new major version. See https://ubuntu.com/security/notices

In jammy we have shipped a Ubuntu patch level update to address a poll()
issue. No other severe bugs or vulnerabilities are currently known in
openssh. If you can disclose a currently non public vulnerability affecting
openssh 8.9 through 9.3 you can do so by contacting Ubuntu Security
desclosure team at  secur...@ubuntu.com or opening an private security bug
report on launchpad against distribution Ubuntu package openssh.

Ps. Please do not use html signatures, especially those that contains ads,
when contacting public mailing lists of opensource projects as that is
considered off topic. You should be able to configure a different signature
when emailing mailing lists, or manually turn it off during compose in your
email client.

--
> 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
>
-- 
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: Choice of the openssl version for 23.10 and 24.04

[Dimitri John Ledkov]

We had similar dilemma around focal release. And I did SRU one off upgrade
from 1.1.0 to 1.1.1. it was a minor disaster. (As in like the sad
depressing songs in A minor scale).

It is best to stick to one openssl version in a release.

It is best to stick to longer supported one.

It is best not to chase minor ones that nobody will use or want long term.

Mantic is open for development, and usually optimisations are fairly
standalone. Even if upstream is not backporting performance optimisations -
we can do so, and have done that for x86, s390x, ppc64el, arm64 in the
past. If there are high priority optimisations that we want in our openssl
we should attempt backports of those onto current openssl release we ship
in mantic.

Note, we would have to then monitor for regressions & security fixes to
those optimisation backports.

On Wed, 17 May 2023, 21:35 Adrien Nader,  wrote:

> On Tue, May 16, 2023, Marc Deslauriers wrote:
> > On 2023-05-15 05:18, Adrien Nader wrote:
> > > Hello,
> > >
> > > Ubuntu currently ships openssl 3.0. Debian will release with 3.0.
> > >
> > > Debian experimental contains 3.1. Openssl 3.1 has been out for a couple
> > > months. It seemed natural to switch to 3.1 which contains a number of
> > > interesting changes including fixes for performance regressions except
> > > that...
> > >
> > > Quoting https://www.openssl.org/policies/releasestrat.html :
> > >
> > > - Version 3.1 will be supported until 2025-03-14
> > > - Version 3.0 will be supported until 2026-09-07 (LTS).
> > >
> > > The support for 3.1 spans two years while the support for 3.0 spans 5
> > > years since it's an LTS.
> > >
> > > If the openssl teams keeps the same cadence (I love extrapolating with
> > > only two data points, it's much simpler), then 3.2 could be released
> > > September 2024 and it could be just in time to be included in 24.10 but
> > > obviously not 24.04. There's also no indication at the moment that 3.2
> > > would be an LTS release. As for 3.3, it would be released March 2026
> and
> > > that would still be early enough to make it the next LTS.
> > >
> > > As I said, these dates are extrapolation based on the 3.0 to 3.1
> release
> > > and I haven't seen communication from the openssl team about their
> > > roadmap besides that they had to remove it at some point because it
> > > needed more work. It's seems unlikely that the result of "more work" is
> > > as simple as "release every 18 months".
> > >
> > > In any case, it seems unlikely that 3.2 is released in time for 24.04
> > > feature freeze AND is an LTS. I'm going to raise this topic on the
> > > openssl issue tracker but I wanted to begin the discussion here since
> > > the same issue is likely to pop again in the future.
> > >
> > > In short:
> > >
> > > In 24.04, do we want to include a release of openssl that will be
> > > supported for "at least two years", possibly starting a year before our
> > > release, or do we want to include a release that will be supported for
> > > "at least five years", possibly starting two years before our release.
> >
> > I'd rather we stick with an OpenSSL LTS release, as that is possibly what
> > others distros will be using and we will be able to collaborate on fixes
> > once the upstream support goes away.
>
> OK. I don't have strong opinions on this, especially since I'm not the
> one who will be pushing security updates.
>
> My main concern is a possible backlash, especially since 3.0's
> performance is sometimes a lot worse than 1.1's and that there won't be
> a newer version in a Ubuntu LTS before 26.04 (
> https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544 is one
> example ).
>

Can this be cherry picked into mantic?




> > > Bonus questions:
> > >
> > > What do we do when the support on the openssl side ends but there's
> > > three more years of support for our LTS releases?
> >
> > We do like we do for all the other packages in our archive, we backport
> > patches to the unsupported version. (And we support our LTS releases for
> a
> > minimum of 10 years now...)
>
> I had forgotten this was now 10 years; I was too set on Bionic's
> schedule.
>
> One advantage of using 3.0 is that it would be the same version as in
> Jammy. Maybe even 26.04 will use it too...
>
> > >
> > > In case we SRU newer versions of openssl, will we attempt to maintain
> > > the same behaviour? (I wanted to ask that question but the answer is
> > > probably not a yes/no: a best-effort policy might make more sense)
> > >
> >
> > We don't SRU newer versions of OpenSSL. The attempts we've made in the
> past
> > to SRU a minor point release resulted in hundreds of fixes required all
> over
> > the archive and caused regressions for users. Backporting security fixes
> and
> > specific bug fixes is the best approach.
>
> Thanks for the explanation.
>
> --
> Adrien
>
> --
> Ubuntu-devel-discuss mailing list
> Ubuntu-devel-discuss@lists.ubuntu.com
> Modify settings or unsubscribe at:
> 

Re: linux-headers-5.15.0-1028-gke for Ubuntu 22.04

[Dimitri John Ledkov]

1) did you try pull-lp-debs as suggested in the first email, and is
that not sufficient to find/download header debs and install them?

2) I have to point out that linux-gke 5.15.0-1028.33 was superseded on
2023-01-06 (more than 4 months ago) by linux-gke - 5.15.0-1024.29

The kernel gke abi you are using is 4 months obsolete and likely
contains multiple publicly known security vulnerabilities. GKE
provides multiple update mechanisms (cluster/image based, or
apt/unattended-upgrades based) , which one should be using to receive
kernel security updates for your cluster. Please contact your GKE
support to investigate why your clusters are not receiving security
updates.

Given your post, and other posts from other GKE users, I am deeply
concerned that many GKE deployments are not receiving updates, which
Ubuntu is publishing for GKE. Note that Ubuntu has no callhome
capability to explain why particular Ubuntu installations are not
downloading and applying security updates.

On Sun, 14 May 2023 at 12:26, Elad Gabay  wrote:
>
> Hi,
> I don't have access to do full host bind mount therefore I can't use headers 
> from the node, I need to be able to fetch the headers from a container\other 
> machine.
> Now I see the same for linux-headers-5.15.0-1030-gke version.
> Thanks
> ________
> From: Dimitri John Ledkov 
> Sent: Saturday, May 13, 2023 03:03
> To: Elad Gabay 
> Cc: ubuntu-devel-discuss@lists.ubuntu.com 
> 
> Subject: Re: linux-headers-5.15.0-1028-gke for Ubuntu 22.04
>
> Caution - External Sender
>
>
> Please see this discussion over here
> https://lists.ubuntu.com/archives/kernel-team/2023-May/139336.html and
> the emails before/later in the thread.
>
> tl;dr Note you have access to headers on the host that you can bind
> mount in the container, you are using obsolete out-of-date kernel ABI.
> You can use `pull-pkg / pull-lp-debs / pull-lp-ddebs` as needed to
> fetch desired packages for Jammy ABI directly from launchpad.
>
> On Sat, 13 May 2023 at 00:51, Elad Gabay  wrote:
> >
> > Hello,
> > Is there a reason that "linux-headers-5.15.0-1028-gke" published only for 
> > Ubuntu 20.04 but not for 22.04?
> > https://packages.ubuntu.com/uk/focal/main/linux-headers-5.15.0-1028-gke
> > Ubuntu – Details of package linux-headers-5.15.0-1028-gke in focal
> > Linux kernel headers for version 5.15.0 on 64 bit x86 SMP
> > packages.ubuntu.com
> >
> >
> > Thanks
> > Elad
> > --
> > 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
>
>
>
> --
> okurrr,
>
> Dimitri



-- 
okurrr,

Dimitri

-- 
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: linux-headers-5.15.0-1028-gke for Ubuntu 22.04

[Dimitri John Ledkov]

Please see this discussion over here
https://lists.ubuntu.com/archives/kernel-team/2023-May/139336.html and
the emails before/later in the thread.

tl;dr Note you have access to headers on the host that you can bind
mount in the container, you are using obsolete out-of-date kernel ABI.
You can use `pull-pkg / pull-lp-debs / pull-lp-ddebs` as needed to
fetch desired packages for Jammy ABI directly from launchpad.

On Sat, 13 May 2023 at 00:51, Elad Gabay  wrote:
>
> Hello,
> Is there a reason that "linux-headers-5.15.0-1028-gke" published only for 
> Ubuntu 20.04 but not for 22.04?
> https://packages.ubuntu.com/uk/focal/main/linux-headers-5.15.0-1028-gke
> Ubuntu – Details of package linux-headers-5.15.0-1028-gke in focal
> Linux kernel headers for version 5.15.0 on 64 bit x86 SMP
> packages.ubuntu.com
>
>
> Thanks
> Elad
> --
> 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



-- 
okurrr,

Dimitri

-- 
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: Building grub2-unsigned from sources on bionic

[Dimitri John Ledkov]

Hi,

On Tue, 14 Mar 2023 at 22:52, Vishwanath Pai  wrote:
>
> Hi All,
>
> I noticed that with the latest update to grub2-unsigned, one of the build 
> dependencies is gcc-10.
> But gcc-10 is not available on bionic. We build ubuntu packages in our build 
> system from source but
> unfortunately we have no way to build the new grub2-unsigned package in our 
> bionic build
> environment.
>
> Also another dependent package: libfuse3-dev is similarly not available on 
> bionic. How is
> grub2-unsigned being built for the official ubuntu repositories?

src:grub2 provided in a given suite is currently buildable in a given
suite. It was changed to exclude building EFI platform code, which is
now built by src:grub2-unsigned, once on one series with one
toolchain, and reused in all ubuntu releases.

Due to multiple recent EFI only vulnerabilties, to reduce security
review and maintenance and debugging/compatiblity checking costs, it
was decided to split src:grub2 into src:grub2 (with all the unsigned
platforms) and src:grub2-unsigned which only contain EFI platform
bootloader without any userspace binaries or dependencies.

If you observe the builds on launchpad, you will notice that
src:grub2-unsigned is built once, and is packaged to ensure that it is
a free standing package without any hard runtime dependencies on the
host system. I.e. open pad.lv/u/grub2-unsigned, click on a desired
version and observe the build
https://launchpad.net/ubuntu/+source/grub2-unsigned/2.06-2ubuntu14.1
you will see that it was compiled in Kineitc once, and published in
all the suites identically bionic; focal; jammy; kinetic. The build
log for each architecture, clearly states that kinetic build-shcroot
was used, and that produced binaries can be published and install in
both older, same and newer series, due to unique engineering we did in
the build process of only that pacakge.

The result of that is signed by Canonical Secureboot keys, and
published from src:grub2-signed package which in turn has per-series
runtime dependencies and versions, but vendors the same identical
build of the signed EFI package.

It is on our plans to provide a gcc-10 toolchain backport, such that
each suite can rebuild the binary package again. However, this will
not reproduce the same result, and may introduce security
vulnerabilities that rely on the toolchain features provided during
build. To reproduce what we have done in the Ubuntu archive, imho it
best to redo what we did - stand up Kinetic builder, build the source
package in Kinetic chroot, sign it with your own keys, rebuild
grub2-signed from scratch pointng at your signed binaries.

Note, rebuilding grub2-unsigned alone is not very useful, as it is not
used on installed systems at all. As the binaries it produces in the
signing tarball, have to be signed (for example we use Launchpad
Signing Service provided in the PPA and Archive builders), and then
revendored back inside grub2-signed. I am assuming you have your own
secureboot signatures, and you rebuild -signed packages yourself with
your own signatures.

If you do not rebuild signed binaries, and do not resign them with
your own secureboot keys, and instead rely on industry wide CA
certificates and using Canonical signed secureboot signatures - then
you probably already skip rebuilding packages such shim / shim-signed,
grub2 / grub2-signed, linux / linux-signed' and thus should also skip
grub2-unsigned.

Please note, this is the same thing we have been doing with shim /
shim-signed packages previously. So please check what you have been
internally doing with shim / shim-signed packages.

If you do not use Secureboot at all, and the split of platform code
that is built by src:grub2 & src:grub2-unsigned of different version
is not useful to you, you could patch those to either use a stock
toolchain, or revert to making src:grub2 package to generate all
bootloader platforms. Depending on what you do, this might be a
reasonable approach, however that will not include fixes for all
publically known vulnerabilities affecting EFI builds.

Please let me know publicly or privately, if this helps, or if you
have any further questions.

-- 
okurrr,

Dimitri

-- 
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: any reason for CONFIG_FUSE_FS=y

[Dimitri John Ledkov]

On Tue, 9 Aug 2022 at 18:29, Bernd Schubert  wrote:
>
>
>
> On 8/9/22 18:38, Dimitri John Ledkov wrote:
>
> >> We are in the process to upstream out changes. We got disrupted by other
> >> work for our main product but will continue to send new patches soon.
> >> However, as expected getting the patches upstream takes time, which is
> >> replacing the module might be helpful.
> >>
> >
> > You can open a bug report in launchpad and attempt to submit pull
> > requests to Ubuntu directly. We do carry many features and backports
> > of features that are in progress of making it into mainline, or are
> > being pulled from maintainer trees. See for example how many SAUCE
> > patches we carry for apparmor, intel cpu features, ibm power cpu
> > features and so on. Depending on how clean and maintained your fuse
> > tree is it might be suitable for inclusion in Ubuntu kernels ahead of
> > vanilla mainline.
> >
>
> Ah nice, for me that sounds great! Maybe that solves our issue! I was
> more expecting a "please open a request through a paying Ubuntu customer".

It's more of a send patches, or pull-requests to Public
kernel-t...@lists.ubuntu.com

But with appropriate messages headers / tags / buglink reference /
sign-off / parent tree etc.

See

https://wiki.ubuntu.com/Kernel/Dev/KernelPatches
https://wiki.ubuntu.com/Kernel/Dev/StablePatchFormat

And so on.

--
okurrr,

Dimitri

-- 
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: Ubuntu initramfs (Was: Re: any reason for CONFIG_FUSE_FS=y)

[Dimitri John Ledkov]

Hi,

On Tue, 9 Aug 2022 at 18:20, Aaron Rainbolt  wrote:
>
> On my system, if the initrd isn't readable by the kernel, it results
> in a kernel panic. Is that to be expected despite inird-less boot? Or
> is that an indicator that at least Lubuntu (and probably Ubuntu
> Desktop) does use an initrd?
>

This is not a choice or a configuration, on machines that we can
guarantee initrd less boot we configure and do that. On machines where
we can't we set it up for booting with initrd. It is a transparent
boot optimisation. If your system boots one way or another, it is best
experience available for you.

But your individual setups and deployments do not represent the
overall spectra of Ubuntu usage, and relative % of boots that happen
one way or the other, even if all of your machines in your particular
deployment do one particular thing.

-- 
okurrr,

Dimitri

-- 
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: Ubuntu initramfs (Was: Re: any reason for CONFIG_FUSE_FS=y)

[Dimitri John Ledkov]

Hi,

On Tue, 9 Aug 2022 at 17:53, Richard Laager  wrote:
>
> On 8/9/22 11:38, Dimitri John Ledkov wrote:
> > The fast majority of Ubuntu installations boot without initramfs at
> > all.
>
> What makes you say this? Every Ubuntu system I've ever installed has an
> initrd.img-KERNEL_VERSION in /boot. In this context, I'm talking about
> systems installed using the stock installers (primarily server, but
> desktop was that way last I installed one using the stock installer).
>

We always generate initrd.img and use it as fallback if/when
initrd-less boot fails. The vast majority of Ubuntu boots are
successful without initrd, for example almost all Ubuntu Public Cloud
images.

-- 
okurrr,

Dimitri

-- 
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: any reason for CONFIG_FUSE_FS=y

[Dimitri John Ledkov]

On Tue, 9 Aug 2022 at 16:24, Bernd Schubert  wrote:
>
> Hi Dimitri,
>
> On 8/9/22 15:54, Dimitri John Ledkov wrote:
> > Hi,
> >
> > On Tue, 9 Aug 2022 at 14:22, Bernd Schubert  
> > wrote:
> >>
> >> Hello,
> >>
> >> I would like to ask if there is a good reason Ubuntu builds fuse as
> >> statically into the kernel instead of using a module?
> >>
> >> Reason I'm asking is that we are currently working on a couple of fuse
> >> improvements and
> >>
> >> a) A static module makes development a bit harder, I cannot take any
> >> quickly installed ubuntu system and just load an updated module, but
> >> always need to install a non custom kernel package.
> >>
> >> b) Makes it impossible to provide the updated module as preview to our
> >> customers, without extra work like renaming all exported symbols and
> >> adding another /dev/something char device to replace /dev/fuse
> >>
> >> c) Makes it hard for us to support customer issues if a fuse issue
> >> should come up (rare case).
> >>
> >
> > Historically this is due to many bugs with dynamically loaded fuse. It
> > is an autoloadable module, thus userspace requesting fuse would
> > autoload it. then later one has to mount /sys/fs/fuse/connections
> > which is all racy. And in practice fuse is often always in use as
> > well. on my system it is common to mount things in nautilus with
> > fuse; lxd/lxc uses fuse; and keybase as well. Also my windows
> > partition is mounted with fuse (not sure why it's not using kernel's
> > module here).
> >
> > you can change ACL methods to not make /dev/fuse accesible; or change
> > udev rules not not even create it; then make your loaded module
> > provide /dev/fuse possibly under a different character device number.
> > You can use linux-backports infrastructure to create a
> > non-symbol-clashing fuse module (see how we build and vendor
> > backports-iwlwifi module). Or something similar.
>
> hmm ok, I would have added "modprobe fuse" in a initramfs script and so
> only users who manually unloaded the module would get issues?
>

The fast majority of Ubuntu installations boot without initramfs at
all. And doing modprobe during early boot would be racy.
Also there becomes a non-trivial upgrade issue, where we have to roll
out a change to modprobe fuse everywhere first, before being able to
change kernel config from y to m.
For no apparent benefit to fast majority of users - just introducing
race / requirement to modprobe fuse.

I will check if static nodes for fuse are pre-created even with the
module not loaded, in which case it might be relatively safish to make
it a module. But given that it is almost always used on both desktops
and servers, I find it counterintuitive to make it a module, and thus
have a tiny module penalty (in terms of bootspeed, loading it from
disk, and having it a module vs builtin).

In general, I do wonder if there are any better kernel mechanisms for
overriding built-in modules.

> >
> > But furthermore If you have an improved fuse module, can we not
> > make it available as part of stock Ubuntu or Ubuntu Pro? If it is
> > useful, and your customers are on Ubuntu, let's make it the best out
> > of the box experience.
> >
>
> We are in the process to upstream out changes. We got disrupted by other
> work for our main product but will continue to send new patches soon.
> However, as expected getting the patches upstream takes time, which is
> replacing the module might be helpful.
>

You can open a bug report in launchpad and attempt to submit pull
requests to Ubuntu directly. We do carry many features and backports
of features that are in progress of making it into mainline, or are
being pulled from maintainer trees. See for example how many SAUCE
patches we carry for apparmor, intel cpu features, ibm power cpu
features and so on. Depending on how clean and maintained your fuse
tree is it might be suitable for inclusion in Ubuntu kernels ahead of
vanilla mainline.

-- 
okurrr,

Dimitri

-- 
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: About Upstream version choice

[Dimitri John Ledkov]

Heya,

On Tue, 9 Aug 2022 at 15:30, Mauricio Faria de Oliveira
 wrote:
>
> Hi,
>
> I'm not directly involved with this in general, but if I understand
> the question and some processes correctly:
>
> The package versions in a given Ubuntu release are (usually) a result
> of a Time Based Release process
> and what package versions are in Ubuntu's and Debian's package
> archives; and there are exceptions.
>
> Ubuntu releases under development import packages (without Ubuntu
> customizations) from Debian
> until the Debian Import Freeze date, and there are packages that are
> Ubuntu-only or replacements
> that thus aren't (imported) from Debian.  There may be more
> details/processes I'm not aware of.
>
> If you check the release schedule wiki page of, e.g., Focal [1], you
> may find some of that information
> and other related topics that might help as well. [2,3,4].
>
> And, of course, others here may correct me / add more information.
> Hope this helps!
>
> [1] https://wiki.ubuntu.com/FocalFossa/ReleaseSchedule
> [2] https://wiki.ubuntu.com/TimeBasedReleases
> [3] https://wiki.ubuntu.com/DebianImportFreeze
> [4] https://wiki.ubuntu.com/Releases
>

All of the above is correct, and then after we release we only do
targetted bug fixes following
https://wiki.ubuntu.com/StableReleaseUpdates process.

At the time when we froze/released Focal Fossa gcc-9.3.0 was the
latest stable release of gcc, which met all of the above timelines.

And we do not upgrade major version of the default gcc toolchain post
GA release, but we do issue bugfix SRUs for it.

Other compilers are available in Focal too, for example you can
install and use gcc-10 as well.

> On Fri, Aug 5, 2022 at 3:31 PM 罗瑶明  wrote:
> >
> > Dear ubuntu-devel-discuss,
> >   I have questions about how to choice or decide which Upstream 
> > version to use for a certain software in Ubuntu Derived series.
> > is there some guiding principle or refer documents. i.e.,why choice 
> > gcc-9.3.0 in the Focal Fossa.
> > 
> > 
> > thanks.
> >
> > --
> > 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
>
>
>
> --
> Mauricio Faria de Oliveira
>
> --
> 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



-- 
okurrr,

Dimitri

-- 
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: any reason for CONFIG_FUSE_FS=y

[Dimitri John Ledkov]

Hi,

On Tue, 9 Aug 2022 at 14:22, Bernd Schubert  wrote:
>
> Hello,
>
> I would like to ask if there is a good reason Ubuntu builds fuse as
> statically into the kernel instead of using a module?
>
> Reason I'm asking is that we are currently working on a couple of fuse
> improvements and
>
> a) A static module makes development a bit harder, I cannot take any
> quickly installed ubuntu system and just load an updated module, but
> always need to install a non custom kernel package.
>
> b) Makes it impossible to provide the updated module as preview to our
> customers, without extra work like renaming all exported symbols and
> adding another /dev/something char device to replace /dev/fuse
>
> c) Makes it hard for us to support customer issues if a fuse issue
> should come up (rare case).
>

Historically this is due to many bugs with dynamically loaded fuse. It
is an autoloadable module, thus userspace requesting fuse would
autoload it. then later one has to mount /sys/fs/fuse/connections
which is all racy. And in practice fuse is often always in use as
well. on my system it is common to mount things in nautilus with
fuse; lxd/lxc uses fuse; and keybase as well. Also my windows
partition is mounted with fuse (not sure why it's not using kernel's
module here).

you can change ACL methods to not make /dev/fuse accesible; or change
udev rules not not even create it; then make your loaded module
provide /dev/fuse possibly under a different character device number.
You can use linux-backports infrastructure to create a
non-symbol-clashing fuse module (see how we build and vendor
backports-iwlwifi module). Or something similar.

But furthermore If you have an improved fuse module, can we not
make it available as part of stock Ubuntu or Ubuntu Pro? If it is
useful, and your customers are on Ubuntu, let's make it the best out
of the box experience.

-- 
okurrr,

Dimitri

-- 
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: package docker.io is broken

[Dimitri John Ledkov]

It says right in the installation log why it is incompatible with your system:

"""
The aufs storage-driver is no longer supported.
Please ensure that none of your containers are
using the aufs storage driver, remove the directory
/var/lib/docker/aufs and try again.
"""

The package prevents breaking your containers which are still
potentially using obsolete storage driver. Make sure you don't have
any containers using obsolete storage driver, and remove the directory
as directed above (which may DESTROY data). And try again.

-- 
Regards,

Dimitri.

On Thu, Nov 18, 2021 at 3:43 PM Tony Emma  wrote:
>
> Hi,
>
> This package "docker.io_20.10.7-0ubuntu5~20.04.2_amd64.deb" seems broken.
>
> My stack trace:
>>
>>
>> # sha256sum 
>> /var/cache/apt/archives/docker.io_20.10.7-0ubuntu5~20.04.2_amd64.deb
>>
>> 27879bc3cdcc6cf6322689bbf92c1a43ab5541346f55a27b604e456893f5a4e7  
>> /var/cache/apt/archives/docker.io_20.10.7-0ubuntu5~20.04.2_amd64.deb
>
>
>
>> # dpkg --debug=1000 -i 
>> /var/cache/apt/archives/docker.io_20.10.7-0ubuntu5~20.04.2_amd64.deb
>>
>>
>>
>> (Lecture de la base de données... 344400 fichiers et répertoires déjà 
>> installés.)
>> Préparation du dépaquetage de 
>> .../docker.io_20.10.7-0ubuntu5~20.04.2_amd64.deb ...
>> The aufs storage-driver is no longer supported.
>> Please ensure that none of your containers are
>> using the aufs storage driver, remove the directory
>> /var/lib/docker/aufs and try again.
>> dpkg: erreur de traitement de l'archive 
>> /var/cache/apt/archives/docker.io_20.10.7-0ubuntu5~20.04.2_amd64.deb 
>> (--install) :
>>  new docker.io package pre-installation script subprocess returned error 
>> exit status 1
>> Des erreurs ont été rencontrées pendant l'exécution :
>>  /var/cache/apt/archives/docker.io_20.10.7-0ubuntu5~20.04.2_amd64.deb
>
>
>>  # uname -a
>>
>> Linux 5.4.0-90-generic #101-Ubuntu SMP Fri Oct 15 20:00:55 UTC 2021 x86_64 
>> x86_64 x86_64 GNU/Linux
>
>
>
>>
>>  # lsb_release -a
>>
>> No LSB modules are available.
>> Distributor ID: Ubuntu
>> Description: Ubuntu 20.04.3 LTS
>> Release: 20.04
>> Codename: focal
>
>
>  Thanks for your help
>
> --
> Best regards,
>
> Tony EMMA
> --
> 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

-- 
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: Feature Request: Remove fwupd in future versions of Ubuntu

[Dimitri John Ledkov]

Hi,

I sympathize with your experience. The firmware updates delivered via fwupd
come directly from the OEM of your hardware. In this case Dell. The
application of dell updates via fwupd, remote management consoles, or via
manually downloaded firmware updates images from their website are
identical. It is likely that you are experiencing hardware issue and should
contact Dell for support. They do test all firmware updates across all of
their SKUs before publishing. It might be a coincidence that firmware
update triggered the fault. It is possible hardware was already defective.

I hope that Dell will be able to help you soon.

Regards.

On Tue, 16 Nov 2021, 15:22 Youran Sun,  wrote:

> Dear Developers of Ubuntu,
>
> I am a several-year Ubuntu user and I install Ubuntu on almost every
> machine I have. I also keep advertising Ubuntu to my friends. However, some
> terrible thing happened yesterday.
>
> Yesterday when I ssh to my PC, which is a Dell Optiplex 7070, the motd
> recommends I update the firmware. I checked the details using `fwupd
> get-updates` as shown in the motd and the outputs seem attractive. So I
> ran `fwupd update`. The update went smoothly and finished successfully.
> Then I reboot. And BOOM! No Logo, no bios, nothing!
>
> Now I cannot even enter bios. The blink pattern of the power light shows a
> "bios checksum error". I have tried for the whole night but no process. It
> seems I have to post my machine to Dell for repair. And the charge may be
> enough for me to buy a new motherboard for this computer.
>
> We know that updating bios is risking and the price of failure is painful.
> How can Ubuntu seduce me to update it while it cannot guarantee success?
> From the perspective of user experience, I suggest Ubuntu not install
> `fwupd` as default, or at least mask `/etc/update-motd.d/85-fwupd`. For
> users who really need an update in bios, they can either install and run
> this program or install the bios using a USB stick, as Dell recommended.
>
> For updates on my poor machine, see Cannot even enter BIOS after update
> .
>
> Sincerely,
> Youran
> --
> 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
>
-- 
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: gnutls plans for focal LTS?

[Dimitri John Ledkov]

On Fri, Oct 1, 2021 at 7:02 PM John Cummings  wrote:
>
> Hello, does anyone know what the plans are for gnutls in Ubuntu 20.04.03 LTS 
> (focal fossa)? It is currently at 3.6.13, and I don't see an update in 
> focal-backports. The recent expiration of a root certificate used in older 
> Let's Encrypt cert paths has triggered a problem in this version, which is 
> fixed in 3.6.14. I see that this fix was backported to gnutls 3.5 in bionic:
> https://bugs.launchpad.net/ubuntu/+source/gnutls28/+bug/1928648
>
> Are there (normally?) plans to add 3.6.14 to focal/focal-backports, or to 
> backport this fix into a 3.6.13 update like was done for bionic?
>
> Thank you!
>

Note that thanks to the ca-certificates package update in focal
https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/1944481
/ https://ubuntu.com/security/notices/USN-5089-1 gnutls operates
correctly with letsencrypt servers with either short or long chains in
all releases of Ubuntu, including Focal's version of the package.

You are correct that focal's version of gnutls is affected and this
may trip up again, whenever the next CA expires. I've added a target
focal series on the gnutls bug report, but not it is not time critical
to fix it at the moment.

Regards,

Dimitri.

-- 
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: autoinstall 20.04 with grub

[Dimitri John Ledkov]

This mailing list is not appropriate for your questions.

This mailing list is for developing the next release of Ubuntu itself.
Not support or discussions around the stable series.

Please join discourse.ubuntu.com to discuss Ubuntu Server installation
options in the server topic - https://discourse.ubuntu.com/c/server/17

There you will find this thread for example
https://discourse.ubuntu.com/t/netbooting-the-live-server-installer/14510

That has step by step guide on booting Ubuntu Server installer over
the network. Specifically the initrd needs to know how to bring up
network, i.e. "ip=dhcp" kernel cmdline option, and where to find the
matching ISO for the kernel/initrd pair one is trying to launch the
installer from i.e.
"url=http://releases.ubuntu.com/focal/ubuntu-20.04.1-live-server-amd64.iso;
if one is booting amd64 with the 20.04.1 media and got the
vmlinuz/initrd pair from it.

Please continue further discussions about the Ubuntu Server installer
on https://discourse.ubuntu.com/c/server/17



On Mon, Jan 18, 2021 at 6:04 PM Jerry Geis  wrote:
>
> I have a current system (grub boot) that I want to replace (its not ubuntu 
> but centos).
> So there  is no USB and no CD.
>
> I am trying to find what to put on the grub linux kernel line to boot up and 
> install everything over teh network.
>
> I have autoinstall working from the USB - but I need it working from 
> "network" only.
>
> I tried this:
> append  initrd=/casper/initrd debian-installer/language=en fsck.mode=skip 
> splash autoinstall ds=nocloud-net;s=https://myip/autoinstall/
>
> but it did not work.  it tries to find the cd at /dev/sr0 and never does of 
> course.
>
> Is there something else I need to specify on the line ?
>
> Thanks
>
> Jerry
> --
> 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



--
Regards,

Dimitri.

-- 
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: Ubuntu 20.04 kickstart

[Dimitri John Ledkov]

live supports autoinstall with simple yaml files to describe the
install which are a lot more simple than either kickstart or preseed.

Have you looked into
https://ubuntu.com/server/docs/install/autoinstall and does that at
all fit your needs?

Alternatively if you have more than 3 servers to provision, have you
tried MAAS? https://maas.io/ it's a small snap that allows
programmatically deploy, and redeploy, any Ubuntu any CentOS etc. In a
reproducible way.

On Wed, Jan 6, 2021 at 8:04 PM Jerry Geis  wrote:
>
> I had to change to legacy CD as live and desktop did not seem to support 
> kickstart.
>
> Can this be re-considered. With the CentOS 8 issues happening - more people 
> might be looking at switching - and kickstart is something they use?
>
> Seems as though kickstart was getting fazed out.
>
> Thanks
>
> Jerry
> --
> 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



-- 
Regards,

Dimitri.

-- 
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: Should one be able to install with only release + -security enabled?

[Dimitri John Ledkov]

On Wed, Nov 25, 2020 at 2:59 PM Nish Aravamudan
 wrote:
>
> Hi!
>
> I have been testing a network-isolated Ubuntu mirror inside our network and I 
> am trying to understand if what I envision should work or not.
>
> In particular, I am trying to minimize how much review is needed for package 
> updates, so I would like to just include the release and security pockets. 
> However, I am finding a few package updates (in Bionic in my case, but I 
> think Focal may also have this problem) that only have fixes in the -updates 
> pocket. This prevents installation from succeeding with preseed.
>
> So far, I have seen apt-setup, but debootstrap and base-installer both need 
> some adjustment for my test environment.
>
> Should we require -updates as well?

Actually it's the security pocket that is optional. It is a fast track
to access SRUs that happen to also contain security fixes at the
fastest speed possible, with automatic download & upgrades by default
via a direct connection to security.ubuntu.com.

When a new security update is prepared, it is based on package version
in updates; security; or release pocket in that order.

Because security update is mandatory to install, and it must not
regress any fixes that already were present in either
updates/security/release.

And then the security update is published into both updates & security
pockets on archive.ubuntu.com & mirrors, as well as onto
security.ubuntu.com host. As it must supersede everything.

When mirroring, we recommend for people to mirror release & updates
pockets. And we advise people to keep security.ubuntu.com
$suite-security archive config as is.

This way all machines can access security updates via a separate
endpoint directly. This insures that if the private mirror is lagging,
the critical security updates still get through to the end-users.

If you must mirror security.ubuntu.com $suite-security, please ensue
it is a separate mirror too. Such that resiliency remains to access
security-updates even if the stock mirror for updates is down for
maintenance.

-- 
Regards,

Dimitri.

-- 
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: Private home directories for hirsute onwards

[Dimitri John Ledkov]

On Thu, Nov 26, 2020 at 2:31 AM Alex Murray  wrote:
>
> setfacl -m u:libvirt-qemu:rx $HOME
>

Similar to above for qemu are there similar setfacl commands, would
something similar be also needed for:
- sshd user to access ~/.ssh/authorized_keys , or nothing needed there?
- in GNOME making ~/Public public?
- giving access to ~/public_html for the www-data user?

If yes, then what are the commands?

I like this approach of selective and explicit setfacl commands to
grant ACLs on per-usecase basis. This is inline with modern ways of
managing permissions.

-- 
Regards,

Dimitri.

-- 
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: Compiling system for Ubuntu

[Dimitri John Ledkov]

Hi,

May I ask you why are you trying to rebuild systemd?

Note that CVE-2020-1712 is fixed in Ubuntu, in all series that it
affects, including 18.04 see
https://people.canonical.com/~ubuntu-security/cve/2020/CVE-2020-1712.html


On Sat, 12 Sep 2020 at 18:15, rafi Moor  wrote:
>
>
>
>
>
> Hello,
>
>
>
> I’m trying here after getting no answers in Ubuntu forums.
>
>
>
> I have hard time compiling some Ubuntu packages from source.
>
> I now try to compile systemd. On Ubunu 18.04 I've used apt source to get the 
> source that is supposed to include Ubunu patches. After compilation, I 
> replace libsystemd-shared-237.so with the one I've compiled. Programs that 
> are linked with this shared object complain about reference to undefined 
> symbol sd_bus_enqueue_for_read. using readelf I can see that the original 
> library has this symbol but the new one doesn't. I've tried to apply 
> CVE-2020-1712-2.patch but then the compilation fails on missing function 
> bus_message_ref_queued(). This function is included in systemd version 246 
> but not in 237 which is the version on Ubuntu 18.04.
>
> How can I compile systemd so that I get files identical to those of Ubuntu 
> 18.04?
>
> Thanks
> Rafi
>
> --
> 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



-- 
Regards,

Dimitri.

-- 
Regards,

Dimitri.

-- 
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: Ubuntu 18.04 and "sig_hashalgo: md4"

[Dimitri John Ledkov]

Hey,

linux kernel upstream has changed how signatures look like in
v5.2-rc1, and only kmod 27 learned how to parse them. But bionic ships
kmod 24, meaning with hwe / cloud kernels, the information printed by
e.g. modinfo is incomplete.

Normally bug reports should be opened in launchpad, i have done so now
at https://bugs.launchpad.net/ubuntu/+source/kmod/+bug/1894611

If this is time critical for you, you could install kmod from focal on
your bionic system (or use it from chroot).

On Sun, 6 Sep 2020 at 01:40, Jeffrey Walton  wrote:
>
> Hi Everyone,
>
> Ubuntu 18.04's modinfo looks like it is subject to
> https://bugzilla.redhat.com/show_bug.cgi?id=1320921 and
> https://bugzilla.redhat.com/show_bug.cgi?id=1490975.
>
> $ modinfo crypto_simd
> filename:   /lib/modules/5.3.0-66-generic/kernel/crypto/crypto_simd.ko
> license:GPL
> srcversion: 701320EC07F22E0D8427859
> depends:cryptd
> retpoline:  Y
> intree: Y
> name:   crypto_simd
> vermagic:   5.3.0-66-generic SMP mod_unload
> signat: PKCS#7
> signer:
> sig_key:
> sig_hashalgo:   md4
>
> A quick Google search did not pick up a similar Ubuntu bug report,
> like Red Hat's 1320921 and 1490975.
>
> It looks like the fix was checked in about a year and a half ago. Also
> see https://lwn.net/Articles/779249/.
>
> Would it be possible to pick up the fix?
>
> Thanks in advance.
>
> --
> 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



-- 
Regards,

Dimitri.

-- 
Regards,

Dimitri.

-- 
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: Dependencies of ubuntu-desktop

[Dimitri John Ledkov]

On Fri, 17 Jul 2020 at 21:23, Andrei Rybak  wrote:
>
> Hello,
>
> I like to use apt and aptitude for my Ubuntu installation. I was
> surprised to find out today, that the packages ubuntu-desktop and
> ubuntu-desktop-minimal do _not_ depend on the package ubuntu-minimal.
> Description of the package ubuntu-minimal claims:
>

ubuntu-minimal is a very small subset of Ubuntu Project that is shared
across all our chroots, containers, builder chroots. All packages in
ubuntu-minimal are Priority important and are always present and
installed on any of our flavours.

ubuntu-minimal by itself cannot boot. It does not ship either
bootloader, kernel, or systemd. It can only be used as a chroot
really. It does however ensure that one can download, authenticate,
and install updates.

> > Description: Minimal core of Ubuntu
> >  This package depends on all of the packages in the Ubuntu minimal system,
> >  that is a functional command-line system with the following capabilities:
> >  .
> >   - Boot
> >   - Detect hardware
> >   - Connect to a network
> >   - Install packages
> >   - Perform basic diagnostics
> >  .
> >  It is also used to help ensure proper upgrades, so it is recommended that
> >  it not be removed.
>
> Could someone please clarify why don't the packages ubuntu-desktop and
> ubuntu-desktop-minimal depend on ubuntu-minimal?  Or, in more general
> terms, what are the packages required for the "Truly Minimal"™ desktop
> installation of Ubuntu?  Would Ubuntu boot to desktop if I remove
> ubuntu-minimal, but keep ubuntu-desktop-minimal?

Removing ubuntu-minimal is not advised.

Your system will no longer be able to authenticate and install any
package updates as that's the seed that pulls in ubuntu-keyring and
apt, among other things.

-- 
Regards,

Dimitri.

-- 
Regards,

Dimitri.

-- 
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: Installing python-is-python3 should affect pip as well.

[Dimitri John Ledkov]

On Fri, 10 Jul 2020 at 00:14, Boris Verkhovskiy  wrote:
>
> When I install python-is-python3, python becomes python3 but I still
> have to type pip3. I think either python-is-python3 should make pip
> into pip3 (which might be surprising to some, since pip3 is installed
> separately) or I would like a pip-is-pip3 and pip-is-pip2 package.
>

I agree. I have opened
https://bugs.launchpad.net/ubuntu/+source/what-is-python/+bug/1887098
to track this. Please subscribe to be notified of the outcome.

-- 
Regards,

Dimitri.

-- 
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: default algorithm in package zram-config 0.5

[Dimitri John Ledkov]

On Mon, 8 Jun 2020, 20:42 Mitch 74,  wrote:

> Hello,
>
> Considering that now lz4 is by default enabled in kernel, wouldn't it be
> better to use it as a compression algorithm in zram instead of lzo?
>

Can you benchmark the performance?

When changing initrd compression we have done extensive benchmarking to
insure we see improvement in the wall clock bootspeed. A data driven
decision can be made here too.

>
-- 
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: Ubuntu Focal Fossa hangs while systemd is setting up on ARM64

[Dimitri John Ledkov]

On Fri, 8 May 2020 at 01:56, Suniel Mahesh  wrote:
>
> Hi All,
>
> I have a board based on Rockchip RK3399 64-bit SOC based on ARMv8A.
> The board can boot from the following devices: Micro SD, EMMC, USB, NVMe SSD.
> I have installed Ubuntu focal fossa with LXDE Display manager(built a 
> headless image
> using Buildroot, downloaded focal-base-arm64.tar.gz and installed all the 
> necessary
> packages with the help of chroot).
> I am using mainline Linux kernel 5.5.10 from kernel.org and mainline u-boot 
> 2020.04.
>
> The board boots fine with ubuntu focal fossa installed on Micro SD, emmc, 
> USB.When the
> board is booted via NVMe SSD(this NVMe SSD is connected via PCIe on to the 
> main board),
> the board loses power(powered off) automatically during the boot process. 
> This happens once
> the kernel loads and it hands over the boot process to systemd and systemd 
> trying to fully load
> ubuntu user space.
>
> In the process of identifying what is causing the problem, I found out that 
> systemd-udevd is the one.
> when loading rules from udev/rules.d, some of them are creating a problem.
>
> so, removed all the rules apart from: 50-udev-default.rules, 60-drm.rules, 
> 90-console-setup.rules,
> 60-block.rules60-serial.rules, 99-systemd.rules. (I know dy doing so, 
> initialization is not properly done)
>
> By doing the above change, I am able to get a basic command prompt. It says 
> the LXDE display manager
> is started but I couldn't get any display on my monitor connected via hdmi.
>
> Can any one please comment on this issue and suggest how to fix the problem. 
> I have attached the hang log.
>

[FAILED] Failed to start Load Kernel Modules.
See 'systemctl status systemd-modules-load.service' for details.

It seems to me that either your kernel config didn't compile required
kernel modules, or you don't have them installed correctly. And given
that you are not using Ubuntu kernel it is hard to debug this.

Instead of using your self-build kernel, can you please try using
Ubuntu kernel ? i.e. v5.4 that we ship for arm on focal?

If you really want the vanilla kernel, instead of building yourself,
can you please try mainline kernel builds as provided by the Ubuntu
Kernel Team at https://kernel.ubuntu.com/~kernel-ppa/mainline/ ?
you will find mainline builds of all upstream kernel releases there
including v5.5 series. v5.5.10 is old they have v5.5.19 prebuilt
there, as well as the v5.6 & v5.7-rc builds.

-- 
Regards,

Dimitri.

-- 
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: Desktop installer is outdated

[Dimitri John Ledkov]

On Sun, 3 May 2020 at 07:34, Haug Bürger  wrote:
>
> Hi,
>
> I just tested the latest 20.04 release in the hope that the installer
> improved. It did not improve. The desktop installer really needs work.
>
> It prefers plain text vs encryption which is not appropriate these days
> and makes Ubuntu insecure. You have to choose extra options to get an
> encrypted setup. If yo do so, it is not possible to create a setup which
> uses multiple disks.

Which layout do you expect to be done, when trying to do both
encryption and multiple disks?

Today, we create luks and create LVM inside that. If you want, you can
add luks on additional drives, and add them as PVs to your LVM as
well. So it is possible to do this as a post-install task. I'm not
sure how to design, or explain what happens when you do that. As one
will be promoted to unlock each encrypted drive separately.

> A different issue is the plain text /boot partition required. This is
> also insecure and unnecessary. This partition reserves fixed space for
> the Kernels, causing issues if to small or wasting space if to big. The
> installer allows it to be any size and doesn't propose a size. Since
> GRUB can boot LUKS devices this is unnecessary.

Unfortunately this is not true. We default to the stronger LUKS2 which
the current grub shipped in 20.04 has no support to unlock. grub only
can unlock the significantly less secure LUKS1 which we no longer
recommend for people to use.

Instead of relying on encryption, we instead use modern firmware
features of ensuring Secureboot & Measured Boot & Lockdown. The only
bootloaders and kernels you  can boot, are those that are chained to
Canonical Master CA UEFI offline certificate, and by default only
signed kernel modules can be loaded. Thus although /boot is not
encrypted, it is impossible to boot untrusted artefacts off it. If one
has TPM one can take further attestation measures to prevent kernel
cmdline being modified too. In the context of enforced secureboot &
enforcing signed kernel modules, what security issues do you see with
unencrypted /boot ?

> The third major issue the missing support for file systems supporting
> snapshots.
>

Desktop installer offers LVM & ZFS installation options, with
snapshots integration in apt and backup software out of the box. Are
snapshots as provided by zfs or lvm not sufficient for you?

> Linux itself supports all of the mentioned short comings. It is possible
> to create encrypted multi disk setups. It is also possible to boot
> directly from the encrypted partition. It is possible to use for example
> BTRFS as root file system, gaining compression and snapshots. It is
> possible to have a swap file on a BTRFS partition. Everything is
> available and the installer should be able to glue it together.
>
> With ZFS on the doorstep it is time to renovate the installer to support
> the new features of modern file systems and bring security i to up to date.
>

Instead we integrated ZFS into our desktop installer, which does
support encryption, and is superior to btrfs in our opinion. Why use
btrfs, when zfs is offered out of the box?

> My question is. Who is in charge for the installer?
>

Ubuntu 20.04 LTS Desktop installer offers the features you deem
essential, is something was not clear in the UI for you to discover
them?

-- 
Regards,

Dimitri.

-- 
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: nvidia-340 incapable of single user mode in 20.04

[Dimitri John Ledkov]

On Mon, 20 Apr 2020 at 20:53, Jack Howarth
 wrote:
>
>   I am finding on a 2008 MacPro with GTX680 that the installation of the 
> nvidia-340 package under Ubuntu 20.04 prevents single user mode boots from 
> working. While the nvidia-340 driver works fine from a normal boot, when 
> 'single' is added before 'quiet' in the grub kernel arguments, the boot 
> produces a black screen that never returns the expected single user mode 
> prompts.
>  A parallel test with current Ubuntu 18.04 with either the stock 
> nvidia-340 340.107-0ubuntu0.18.04.4 package or the 
> nvidia-graphics-drivers-340 340.108-0ubuntu0.18.04.1 show both of them can 
> successfully boot into single user mode.
> Jack

nvidia-340 is a very old version of nvidia.

20.04 LTS has: nvidia-driver-390, nvidia-driver-435, nvidia-driver-440.

Can you please use Super to search and launch "additional drivers"
select 440 driver and install and try that one? It is the recommended
version of nvidia on 20.04 LTS. Or whichever is highest and supports
your nvidia card.

-- 
Regards,

Dimitri.

-- 
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: UBUNTU ARM64 DEB PACKAGES on DEBIAN RELATED VERSION

[Dimitri John Ledkov]

All of Ubuntu is available for arm64 & armhf

Why bother with Debian, if all of Ubuntu is available anyway?!

On Mon, 23 Mar 2020, 19:28 Onur GURSOY,  wrote:

> Hello Everyone,
>
> First of all you're great team. you done great jobs.
> I'm lovers of arm and you're supporting arm platform.
> I'm very appreciated to you.
>
> I'm wondering one thing nowadays, I'm interested in ubuntu packaging for
> ar,64 platform. I'm inspecting your package and your .dsc file.
> *Your ubuntu arm64 packages are working on debian ?*
> I mean, your freeradius_3.0.16+dfsg-1ubuntu3.1_amd64.deb is working on
> DEBIAN buster/sid.
> In general, you are doing something for ubuntu for packaging ?
> *I can say, Most of ubuntu packages are fully **compatible with debian
> buster/sid or something like that version?*
>
> Many thanks,
> for your help,
> With best regards,
>
> --
> Onur GÜRSOY
> R Engineer in Embedded Systems
> Master Student at Gebze Institute Of Technology
> Department Of Electronic Engineering
> GSM : 0(545) 764 7653
> e-mail: onurgursoyg...@gmail.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
>
-- 
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: Some ideas about APT functionality

[Dimitri John Ledkov]

Hi,

On Sun, 11 Aug 2019 at 21:37, Mike  wrote:
>
> Today, to properly install rpm-packages on my laptops, I'm running

Which rpm packages are they? For which architectures? Is .deb
available? Or snap? If not, have you tried reaching out to the vendor
to provide snap/deb? Do you want us to reach out to them?

-- 
Regards,

Dimitri.

-- 
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: Re: ask for support packages for nfs-kernel-server

[Dimitri John Ledkov]

On Sat, 18 May 2019 at 16:21,  wrote:
>
> Hello Dimitri, Nish,
>
> @Dimitri
>
> I'm lucky to solve the problem with the indication of this site:
>
> https://askubuntu.com/questions/91815/how-to-install-software-or-upgrade-from-an-old-unsupported-release
>
> I think your suggestion is more from a developer point of view while the 
> above one is more from a user point of view.
>
> I tried your solution after applying the first method. It also works in the 
> chroot environment. Thanks!
>
> By the way, can we use mk-sbuild to create a cross develpment environment 
> (eg: a toolchain for ARM board on a IA32 machine) If it is not possible, why? 
> Thanks!
>

Yes you can.

$ mk-sbuild --target=armhf bionic

Will create a crosscompilation chroot from host arch (ie. amd64) to
armhf. Do observe the commands printed at the end to pass those
options to sbuild to cleanly crossbuild the packages.

> @Nish
>
> Thanks for you answer!
>
> Best regards
> Chenghao
>
>
>
> - Original Message -
> From: Dimitri John Ledkov 
> To: wangchenghao2...@sina.com
> Cc: ubuntu-devel-discuss 
> Subject: Re: ask for support packages for nfs-kernel-server
> Date: 2019-05-15 23:00
>
>
> On Thu, 9 May 2019 at 18:31,  wrote:
> >
> > Dear,
> >
> > I'm trying to install the package nfs-kernel-server on my Ubuntu 10.04.
> >
> > By the apt-get command, the following package are needed:
> > libgssglue1_0.1-4_i386.deb
> > libnfsidmap2_0.23-2_i386.deb
> > librpcsecgss3_0.19-2_i386.deb
> > portmap_6.0.0-1ubuntu2_i386.deb
> > nfs-common_1.2.0-4ubuntu4_i386.deb
> > nfs-kernel-server_1.2.0-4ubuntu4_i386.deb
> >
> > I cannot found the exact version for libgssglue1, libnfsidmap2 and 
> > librpcsecgss3. (I think it's due to the expired support of the Ubuntu 
> > version.) I tried the closest version of these packages that I can find. 
> > But there are dependency problems.
> >
> > I have spent a whole day trying to resolve it without success. Can you help 
> > to provide these pakcages? Thanks a lot!
> >
> > Best regards
> > Chenghao WANG
>
> As part of sunsetting obsolete ubuntu releases, they do get archived
> to old-releases, and both installation media and the apt archive are
> still available as a a final snapshot only.
> So one can still consume that, even from a modern amd64 Ubuntu
> release, for example:
> $ mk-sbuild lucid --arch=i386
> --debootstrap-mirror=http://old-releases.ubuntu.com/ubuntu/
> --debootstrap-keyring=/usr/share/keyrings/ubuntu-archive-removed-keys.gpg
> $ schroot -c lucid-i386 -u root
> $ apt-get install nfs-kernel-server
> (downloads and installs all the packages one needs)
> Enjoy, but do please upgrade to Ubuntu 18.04 LTS Bionic!
> --
> Regards,
> Dimitri.



-- 
Regards,

Dimitri.

-- 
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: ask for support packages for nfs-kernel-server

[Dimitri John Ledkov]

On Thu, 9 May 2019 at 18:31,  wrote:
>
> Dear,
>
> I'm trying to install the package nfs-kernel-server on my Ubuntu 10.04.
>
> By the apt-get command, the following package are needed:
> libgssglue1_0.1-4_i386.deb
> libnfsidmap2_0.23-2_i386.deb
> librpcsecgss3_0.19-2_i386.deb
> portmap_6.0.0-1ubuntu2_i386.deb
> nfs-common_1.2.0-4ubuntu4_i386.deb
> nfs-kernel-server_1.2.0-4ubuntu4_i386.deb
>
> I cannot found the exact version for libgssglue1, libnfsidmap2 and 
> librpcsecgss3. (I think it's due to the expired support of the Ubuntu 
> version.) I tried the closest version of these packages that I can find. But 
> there are dependency problems.
>
> I have spent a whole day trying to resolve it without success. Can you help 
> to provide these pakcages? Thanks a lot!
>
> Best regards
> Chenghao WANG

As part of sunsetting obsolete ubuntu releases, they do get archived
to old-releases, and both installation media and the apt archive are
still available as a a final snapshot only.

So one can still consume that, even from a modern amd64 Ubuntu
release, for example:

$ mk-sbuild lucid --arch=i386
--debootstrap-mirror=http://old-releases.ubuntu.com/ubuntu/
--debootstrap-keyring=/usr/share/keyrings/ubuntu-archive-removed-keys.gpg
$ schroot -c lucid-i386 -u root
$ apt-get install nfs-kernel-server
(downloads and installs all the packages one needs)

Enjoy, but do please upgrade to Ubuntu 18.04 LTS Bionic!

-- 
Regards,

Dimitri.

-- 
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: biosdevname package in Universe is severely downlevel

[Dimitri John Ledkov]

On Wed, 24 Apr 2019 at 20:47, Jeffrey Lane  wrote:
>
> Hi.  I've been in touch with Mellanox who had filed this bug [1]
> against the biosdevname[2] package in Universe.  Somehow, this package
> ended up in Universe, with someone named Rudy Gevaert
>  listed as the Original Maintainer and Ubuntu
> Developers  as the package
> maintainer.
>
> This package is SORELY out of date and has not been updated since the
> 4.0-1 version was introduced in Ubuntu.  There have been several
> updates since then as shown at the Dell host site[3] while the Ubuntu
> package has languished.  The net effect of this is that this package
> in Ubuntu is broken on pretty much all modern mellanox NICs (CX4,
> CX5).
>
> What can we do to get this updated in Eoan and then backported into Bionic?
>

Imho it should be removed from the archive, and not be made available at all.

Why is biosdevname installed or used at all? Does udev not provide
stable names as it is already? And if not can it be fixed there or
not?

(i know that some of the stable name ids are not available in stock
udevd, but i believe the solution there was to start maintaining out
of systemd tree udev util to give out persistent names)

A demotion of a package from main to universe, does indicate that it's
no longer used by default nor recommended for usage by default.
Especially something that renames interfaces unlike any other Linux
distribution out there.

> Cheers
> Jeff
>
> [1] https://bugs.launchpad.net/ubuntu/+source/biosdevname/+bug/1535045
> [2] 
> https://packages.ubuntu.com/search?keywords=biosdevname=names=all=all
> [3] http://linux.dell.com/files/biosdevname/
> --
> Jeff Lane
> Technical Partnership and Server Certification Programmes
>
> "Entropy isn't what it used to be."
>
> --
> 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



-- 
Regards,

Dimitri.

-- 
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: Right way to submit patches for Ubuntu packages

[Dimitri John Ledkov]

Hi,

On Fri, 12 Apr 2019 at 22:26, Jonathan Behrens  wrote:
>
> I've been trying to get a two line patch merged for `gdb-multiarch`. Debian 
> accepted it almost right away, but subsequent releases for Ubuntu haven't 
> included it. About a month ago I tried submitting directly on Launchpad but 
> that has seemingly been ignored as well. Have I submitted the patch 
> incorrectly? Or is there some reason that it shouldn't be merged?
>

Ubuntu normally merges packaging changes from Debian continuously
whilst the development is open up to the Debian Import Freeze /
Feature Freeze. Which for the Disco Dingo release was on 21st of
February.
I think your patch was uploaded into debian on the 22nd of February.
And whilst we do fix, merge and upload things post Feature Freeze it's
progressively more conservative / higher priority things.
I am afraid, that bugfix, possibly missed the 19.04 cycle by a day, effectively.
Once we open EE cycle for development, I'm sure it will be merged into
Ubuntu then =/

Sorry about that.


-- 
Regards,

Dimitri.

-- 
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: anyone still use 'import-bug-from-debian'?

[Dimitri John Ledkov]

On Wed, 13 Feb 2019 at 13:42, 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?
>

I used to use it, but last few times I have tried to do it, it either
failed to open the bug report, or it was incomplete - as in, it didn't
copy the body of the bug as it used to. At the time, I did not have
time to dig into the import-bug-from-debian code to fix it up.

I'd use it more, if it's known to work again.

-- 
Regards,

Dimitri.

-- 
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: g++-multilib omissions

[Dimitri John Ledkov]

On Sat, 15 Dec 2018 at 23:36, Daniel Llewellyn  wrote:
>
> Hi,
>
> I've been looking through the g++-multilib package, and I _think_ there is an 
> accidental omission or misconfiguration. It seems that none of the packages 
> produced target the arm64 or ppc64el architectures which Ubuntu supports. 
> There is a configuration for ppc64 packages, but I don't believe Ubuntu 
> supports that particular architecture definition (favouring ppc64el)?
>
> Am I correct in my understanding? Should I attempt to resolve this with a 
> non-maintainer-upload and SRU (noting that I'm not very familiar with deb 
> packaging), or can someone who knows the packages better advise?Tho
>

Those are non-multilib arches I think you want to use
g++-aarch64-linux-gnu and g++-powerpc64le-linux-gnu without any
switches (ie. without -m64 or anything like that), which is available
on "developy" amd64/i386/ppc64le architectures. Would that be enough
for your use cases?

-- 
Regards,

Dimitri.

-- 
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: Cosmic Cuttlefish (18.10) Final Freeze

[Dimitri John Ledkov]

Hi,

On Fri, 12 Oct 2018 at 19:04, Liviu Beraru  wrote:
>
> Hi,
>
> I get these email since years although I have tried many times to unsubscribe.
> Can you do something to delete me from all ubuntu mail lists?
>

It's impossible for us to know which email address you have signed up
with, and to know how you are receiving these emails. In gmail
interface expand Adam's email, then open the tripple dot drop down
menu on the right, click "Show Original" and look for 'Delivered-To:'
header, should be first / at the very top, of the small print emails.
That should be the email you are getting deliveries to.

Once you find that, go to
https://lists.ubuntu.com/mailman/listinfo/ubuntu-announce and enter
your delivery address at the very last field next to Unsubscribe or
edit options. From there you should be able to unsubscribe. Remember,
you must confirm unsubscription!

Regards,

Dimitri.


> Thanks,
> Liviu
>
> On Thu, Oct 11, 2018 at 11:30 PM Adam Conrad  wrote:
>>
>> As of nowish, cosmic has entered the Final Freeze period in preparation
>> for the final release of Ubuntu 18.10 next week.
>>
>> The current uploads in the queue will be reviewed and either accepted
>> or rejected as appropriate by pre-freeze standards, but anything from
>> here on should fit two broad categories:
>>
>> 1) Release critical bugs that affect ISOs, installers, or otherwise
>>can't be fixed easily post-release.
>>
>> 2) Bug fixes that would be suitable for post-release SRUs, which we
>>may choose to accept, reject, or shunt to -updates for 0-day SRUs
>>on a case-by-base basis.
>>
>> For unseeded packages that aren't on any media or in any supported
>> sets, it's still more or less a free-for-all, but do take care not to
>> upload changes that you can't readily validate before release.  That
>> is, ask yourself if the current state is "good enough", compared to
>> the burden of trying to fix all the bugs you might accidentally be
>> introducing with your shiny new upload.
>>
>> We will shut down cronjobs and spin some RC images late Friday or early
>> Saturday once the archive and proposed-migration have settled a bit,
>> and we expect everyone with a vested interest in a flavour (or two) and
>> a few spare hours here and there to get to testing to make sure we have
>> another uneventful release next week.  Last minute panic is never fun.
>>
>> On behalf of the Ubuntu Release Team,
>>
>> ... Adam Conrad
>>
>> --
>> ubuntu-devel-announce mailing list
>> ubuntu-devel-annou...@lists.ubuntu.com
>> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce
>
> --
> 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



-- 
Regards,

Dimitri.

-- 
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: An question about default opened option "-fstack-protector-strong"

[Dimitri John Ledkov]

On 14 June 2018 at 08:03, Shao, Ting  wrote:
> Hi,
>
> I was trying to enable the “stack smashing protection” for node.js(issue
> 20928). And I switched it on using “-fstack-protector”
> And made a benchmark test, while the result is quite strange. Then I found
> on my Ubuntu 16.04, the –fstack-protector-strong
> Was by default enabled. I checked it using the command:
>
> Gcc –Q –v main.c
>
> And found the –fstack-protector-strong flag was listed inside the “options
> passed” by default.
>
> So based on these, I have some questions:
>
> I installed gcc from apt-get by default, is Ubuntu providing a customized
> version of GCC?
> If answer of 1 is yes, then you may have a repo that host the customized GCC
> code, if I am right, could you please show me where I can find the proof of
> that customization?
>
> That would be much appreciated. J Or if you can’t find the right code, can
> you show me where I can find the repo, then I can traverse the code and
> history to find the proof myself.
>

Some of our default toolchain flags are documented at:
https://wiki.ubuntu.com/ToolChain/CompilerFlags

Security-related distribution features (which include many toolchain
customizations) are documented at:
https://wiki.ubuntu.com/Security/Features

The userspace hardening section does mention "Note: Ubuntu's compiler
hardening applies not only to its official builds but also anything
built on Ubuntu using its compiler." This ensures that self-compiled /
3rd-party code has on-par security when redistributed, or when
targetting Ubuntu platform. The Ubuntu toolchain is an integral part
of the Ubuntu product line.

-- 
Regards,

Dimitri.

-- 
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: About the Ubuntu Server in the Azure virtual machine gallery

[Dimitri John Ledkov]

Hi,

On 27 May 2018 at 20:52, Tong Sun  wrote:
> Hi,
>
> I see that in the Azure virtual machine gallery, it lists:
>
> Ubuntu Server
> https://azuremarketplace.microsoft.com/en-us/marketplace/apps/Canonical.UbuntuServer?tab=Overview
> Canonical
>
> Does it means that Canonical is responsible for creating such Azure virtual
> machines, or just this Ubuntu Server is copyrighted to Canonical?
>
> Basically I want to understand why the latest Ubuntu 18.04 LTS is still not
> available from the Azure virtual machine gallery yet, as it's been available
> for quite a while now. Thx.
>

The Ubuntu Project and Canonical build and publish these images in
azure marketplace.

Ubuntu 18.04 LTS is available, and you can find and launch it using
e.g. the Azure CLI.

However, the gallery is maintained by Microsoft. The change to include
Ubuntu 18.04 LTS is in the process of rolling out across all the
regions. So Ubuntu 18.04 LTS should be available in the gallery soon.

-- 
Regards,

Dimitri.

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

[Dimitri John Ledkov]

On 13 May 2018 at 21:13, Oliver Grawert  wrote:
> hi,
> Am Sonntag, den 13.05.2018, 14:33 -0400 schrieb Jeremy Bicha:
>> On Sun, May 13, 2018 at 1:57 PM, Colin Watson 
>> 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
>>
>
> note that today the ability of executing 32bit snaps on top of amd64 is
> achieved via the installation of libc6:i386 inside the core snap ...
>
> with the i386 archive gone we'd need a new solution here ...

Which is to install libc6-i386:amd64 package no? Is this an all snap
system? Do you have any other :i386 packages installed? Imho, it may
make sense to switch to using libc6-i386:amd64 in core / on all-snap
systems.

-- 
Regards,

Dimitri.

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

[Dimitri John Ledkov]

On 11 May 2018 at 16:32, Fiedler Roman  wrote:
>
> > Von: ubuntu-devel [mailto:ubuntu-devel-boun...@lists.ubuntu.com] Im
> >
> > Hello,
> >
> > Less and less non-amd64-compatible i386 hardware is available for
> > consumers to buy today from anything but computer part recycling centers.
> > The last of these machines were manufactured over a decade ago, and
> > support from an increasing number of upstream projects has ended. ...
> >
> > ...
>  >
> > We still have a relatively high number if i386 downloads but that doesn't
> > mean users machines are not capable of amd64. For the flavors remaining
> > today on i386 here are some i386 to amd64 ratios for 18.04:
> >
> > Lubuntu cdimage - 0.87
> > Lubuntu tracker - 0.64
> > ...
>
> This decision is not only about numbers, but somehow also about ethics. The 
> number of e.g. wheel-chair users or other disabled persons might not be 
> relevant for a society/economy in terms of numbers. But we honor the value of 
> freedom, also for those, who are not that well off than we are. Those would 
> not be able to participate in the same way, if we would not assist them by 
> providing support for that minority.
>
> So for the i386 discussion, there might be only two distinct groups of users 
> worth considering:
>
> a) Those, who cannot afford newer systems due to economical reasons.
>
> b) Those, who do not want to consume more resources due to ethical 
> considerations (that's the one for me): how many people could fed or how much 
> CO2 prevented, if all systems were some percent smaller on disk/RAM, 
> including IT-system production and operation related resource usage? Wasting 
> resources is also about freedom, as we deprive others who cannot afford 
> them/fight for them in the same way we can do.
>

"Consume more resources" is a bit vague. Environmental impact is
correlated with performance-per-watt measurements. That improves with
the newer generation of lithography, better support of newer and more
efficient instruction sets, ability to dynamically clock-down cpu
cores etc. Thus newer generation CPUs are better performance wise on
environment front. Depending on how much newer it is, it may even make
economic sense to upgrade old hardware. Unless one operates complete
off-grid, on self-harvested renewable energy, e.g.
https://identi.ca/joeyh/note/mSMKXM3gSluoeC5mP1xIsw

An example of this is comparing Intel Core Duo (65nm litography) as
used in the last 32bit only Macbook from 2006 with the MacBook Retina
(14nm) from 2015 about 10 years gap. The same number of cores, with
comparable maximum frequency, Yet Thermal Design Power went down from
31W to 4.5 W (turbo 6W, low 3.5W, target average 4.5W). Dissipated
heat is a proxy measurement for environmental impact. And the fact
that later models are now fan-less, indicates better thermal dynamics,
less power consumption, and overall nicer for the environment.

I beat myself up a bit for still using a 22nm Ivy Bridge CPU with TDP
of 77W, when I can get a new tower for less than 300 quid, which would
come with a 14nm processor and TDP of just 35W. Electric saving alone
for me would be at least 40 quid per annum.
I have at least migrated my always-on servers to ARM64.

HDDs consume more energy than SSDs; similarly newer (faster
clock/dynamicly clocked, and operating at a lower voltage / amps) RAM
consume less energy. If newer platforms were not more power efficient,
we would not see public clouds / datacentres upgrading their platforms
as aggressively as they do.

The question comes down to, that some users simply cannot afford any
upgrades at all. That makes me feel sad, and it is an indicator of
poverty to me. I hope such users have access to and are better served
by mobile phones / tablets with ARM processors for basic computing,
information and communication needs. But I also fear that such users
cannot afford to download security updates and choose to spend their
MBs on downloading web pages and communicating instead.

Doing a brief search in the UK there appear to be charities /
sponsored schemes for affordable computing
https://www.choose.co.uk/guide/free-computer-schemes-on-benefits.html
and for around 100 quid one can get multi-core 64-bit based, 3GB of
RAM desktops, laptops, netbooks. See for example
http://www.getonlineathome.org/ . I do not see it as prohibitively
unattainable, but I do guess this is still a luxury and not the case
for many other countries around the world.

-- 
Regards,

Dimitri.

-- 
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: [Artful Aardvark] Security issue in the packaged version OCaml

[Dimitri John Ledkov]

On 7 October 2017 at 16:56, Benjamin  wrote:
> Hello,
>
> I am Ubuntu user working with OCaml. I am glad to see that the Artful
> Aardvark release of Ubuntu comes with the 4.04.0 release of the OCaml
> compiler. However, it appears that the 4.04.0 (and the 4.04.1) release
> contains a security flaw[1].
>
> As this security flaw is fixed in the 4.04.2 release of the compiler,
> and as this release of the compiler is fully compatible with 4.04.0,
> maybe should it be welcome to upgrade the packaged version of OCaml to
> 4.04.2?
>

ocaml is very abi sensitive, thus even a minor update like that may
trigger change of the magic provides triggering recompiles.

Also given how late in the cycle we are, it's best to handle this just
like any other security update in ubuntu - specifically doing a
targetted cherrypick of the security bugfix only.

I'm preparing such an update.

No other releases are affected as per
https://people.canonical.com/~ubuntu-security/cve/2017/CVE-2017-9772.html

-- 
Regards,

Dimitri.

-- 
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: Launchpad builder changes: schroot and LXD

[Dimitri John Ledkov]

On 6 September 2017 at 12:36, Colin Watson  wrote:
>
> As of launchpad-buildd 149, deployed to production on 2017-09-04, the
> following changes are effective on Launchpad's build farm:
>
>  * sbuild (used to build .debs from source packages) uses its schroot
>mode to perform chroot operations rather than sudo.  This is closer
>to how Debian builders behave and to how developers typically run
>sbuild interactively, and it means that the inactivity timeout
>actually works properly rather than leaving builds in a state where
>they have to be cancelled manually.
>
>There are some small differences in the environment observed from
>inside a build, of which the most important are probably that HOME is
>now set to a nonexistent directory, and V=1 is set to cause various
>build systems to be more verbose (we made this change in 2014 but it
>was lost somewhere along the way).  See [1] for more details.
>

There have been, at least in the past, packages in ubuntu that do rely
on HOME being a real directory and would FTBFS locally when HOME
pointed to non-existant directory, but would build fine in launchpad.

Hence I have 'HOME' => '/build/' in my ~/.sbuildrc. I shall drop that
now, to match launchpad's new behavior.

But something to be aware of.

>  * Snaps and live filesystems are now built in LXD containers rather
>than in chroots, laying the groundwork for them to be able to install
>snaps as build-dependencies.
>
> At the moment the only known regressions from this are in some corner
> cases of live filesystem building (powerpc and CPC).  Let us know if you
> see anything else amiss, although as usual please try to reproduce
> problems locally before attributing them to the build environment.


This has been noticed for the CPC case, and is trivially reporducible
with lxd and the OddBloke's cloud builder. I had an updated lxd
profile from steve that supposedly does work, shall I test that, and
do you need the updated (less restrictive) lxd profile for the devirt
CPC livecd builds? A priviledged lxd container alone is not enough
there.

-- 
Regards,

Dimitri.

-- 
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: liblangtag 0.5.8 in LTS 16.04

[Dimitri John Ledkov]

On 2 July 2017 at 08:25, Andre Matzke  wrote:
>
> Hello Dearest Repo Maintainers,
>
> would it be possible to consider integrating version 0.5.8 in LTS 16.04?
>
> meanwhile using openoffice-support in owncloud a permanent code
> integrity check problem - warning is displayed on top in owncloud.
>
> this is due to a bug in liblangtag 0.5.7, which is resolved in 0.5.8.
> since 2 years..
>

We do not upgrade to newer version of things; but we do upload patches
to fix individual bugs.

What is the bug? Do you have a URL to the upstream patch / upstream bug report?

Please open a bug on launchpad against liblangtag discribing all of
that using this template:
https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template

Then the process of fixing liblangtag you knwo about can be started.

Regards,

Dimitri,

-- 
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: btrfs tools patch for quiet output from send

[Dimitri John Ledkov]

Hello,

On 28 May 2017 at 20:21, Lucas  wrote:
> Any chance we can get this patch backported to Xenial?
>
> https://github.com/kdave/btrfs-progs/commit/09c052a8b4dcaa96fe5e6c28b12ce24729e827a4
>
> At the moment, people are doing clunky work-arounds to suppress unwanted "At
> subvol" messages. E.g. btrbk. I know I'd like to see output from actual
> errors only, in my scripts.
>

This sounds useful. Could you please open a bug with $ ubuntu-bug btrfs-progs

and state above? And give me the bug number?

Unless there is a bug open, it is unlikely to get picked up for an SRU.

-- 
Regards,

Dimitri.

-- 
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: Upcoming Vacant Developer Membership Board seats: Second call for nominations

[Dimitri John Ledkov]

On 20 May 2017 at 03:25, Jeremy Bicha  wrote:
> On Fri, May 19, 2017 at 6:52 PM, Brian Murray  wrote:
>> The DMB is responsible for reviewing and approving new Ubuntu developers
>> [1], meeting for about an hour once a fortnight. Candidates should be
>> Ubuntu developers themselves, and should be well qualified to evaluate
>> prospective Ubuntu developers and decide when to entrust them with
>> developer privileges or to grant them Ubuntu membership status.
>
> Given the apparent difficulty in finding volunteers, please clarify
> whether nominees are required to first be members of ~ubuntu-core-dev.

They are not. E.g. Laney was not a core-dev for a long time, whilst
being on the DMB.

-- 
Regards,

Dimitri.

-- 
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: Keyboard layout switching in modern Ubuntus

[Dimitri John Ledkov]

On 1 May 2017 at 22:40, Nrbrtx  wrote:
> Dear Ubuntu developers!
>
> I have just upgraded my machines from 12.04 to 14.04.
>
> After upgrades I discovered that there are some issues with keyboard layout
> switching.
> I have two keyboard layouts - English and Russian.
> I prefer to install GNOME FlashBack session into normal Ubuntu (Unity)
> flavor.
> I tried to set my favourite keyboard layout switching shortcut ,
> but it does not switch keyboard layouts.
> I tried both GNOME FlashBack with Metacity and Compiz sessions. My shortcut
> does not switch layouts. Even on clean minimal install.
> Of course it works on Unity, but I use it very seldom on one netbook.
>
> Previously I suggested to add test-suite for GNOME FlashBack sessions with
> no positive results (see bug 1604466).
> I reported new bug 1687466.
> I can't set  because of interference with other 
> shortcuts (see bug 1245473).
> As temporary solution I set , but it is unusual.
>
> My questions are:
> 1. Is it possible to use  as keyboard layout switcher in GNOME
> FlashBack sessions?
> 2. Do you plan to fix  interference?
> 3. Why we have both gnome-control-center and unity-control-center on simple
> system with GNOME FlashBack?
> 4. What is the future of unity-control-center?

Standard keyboard layout switching combination has been Super +
Spacebar for a few years now.
This is consistent on the cross-OS basis, including Mac OS X and
Mircosoft Windows I believe.

-- 
Regards,

Dimitri.

-- 
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 for update pkg

[Dimitri John Ledkov]

Hello,

On 24 January 2017 at 07:47, Василий Петрович  wrote:
>
> Hello! In 2.11 version of Pidgin many security bugs fixed 
> https://pidgin.im/news/security/ Can you update pidgin in ubuntu repository? 
> Regards.
>

in Ubuntu we cherry-pick individual patches to fix security issues.

From https://launchpad.net/ubuntu/+source/pidgin/1:2.10.12-0ubuntu5.1
I can see that security fixes are in Ubuntu 16.04 LTS release already
since July 2016.

Please note that pidgin is in Universe and security updates to it rely
on community involvement.

You can use security tracker at
https://people.canonical.com/~ubuntu-security/cve/ to check for CVE
and their current status. Pidgin package is currently not affected by
any known CVEs in any supported Ubuntu releases.

Regards,

Dimitri.

-- 
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: canonical livepatch

[Dimitri John Ledkov]

On 4 November 2016 at 12:44, kallinikos Evangelopoulos
<kallinikos2...@yahoo.gr> wrote:
> Thanks very much for the answer. I just checked again, this time with
> --verbose and a reboot, as you suggest, and I got this:
>
> kernel: 4.4.0-45.66-generic
>   running: true
>   livepatch:
> state: nothing-to-apply
> version: ""
> fixes: ""
>
> So, it does seem fine, except for the version again, which appears nowhere,
> unlike everyother instance I managed to see, even yours. Are you sure this
> does not pose a problem? It is strange, isn't it?
>

That doesn't seem strange to me. The version string should be that of
the livepatch kernel module to apply. Currently, there are no
livepatches applied or available to be applied, and hence the version
string is empty.
Note that multiple livepatch versions can be applied against a given
kernel. So, for example, if I don't reboot my machine, and there are
further livepatches released for my currently running kernel then my
version string will keep incrementing whilst the kernel version will
stay the same.

Does above make sense at all?

/me is very new to using livepatches too

Regards,

Dimitri.


> Regards,
>
> Kall
>
>
> Στις 1:29 μ.μ. Παρασκευή, 4 Νοεμβρίου 2016, ο/η Dimitri John Ledkov
> <x...@ubuntu.com> έγραψε:
>
>
> Hello,
>
> On 4 November 2016 at 09:00, Christian Ehrhardt
> <christian.ehrha...@canonical.com> wrote:
>> Hi,
>> just checked, with the same kernel mine still looks today like yours did
>> initially.
>> If run the status command with --verbose it will list the status it is in,
>> which might help seeing whats going on on your system.
>>
>
> Well if you reboot every day, then you boot the kernel which is fully
> patched - with all security (not just severe ones) and bugfixes. Such
> kernels are released at the same time as livepatches.
> I.e. if one can afford reboots, one is fully up to date.
>
> Plus this service is currently running for xenial only.
>
> I don't like rebooting my desktop. Hence I have:
>
> $ uptime
> 11:25:14 up 24 days,  7:20,  3 users,  load average: 3.15, 2.50, 2.20
>
> $ lsmod | grep live
> kpatch_livepatch_Ubuntu_4_4_0_38_57_generic_1349152  1
>
> $ sudo canonical-livepatch status --verbose
> client-version: "5"
> machine-id: censored
> machine-token: censored
> architecture: x86_64
> cpu-model: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz
> last-check: 2016-11-04T11:07:47.882167806Z
> boot-time: 2016-10-11T05:05:04+01:00
> uptime: 583h20m17s
>
> status:
>
> - kernel: 4.4.0-38.57-generic
>   running: true
>   livepatch:
> state: applied
> version: "13.3"
> fixes: ""
>
> Maybe I should reboot into a newer kernel 38 -> 45. If you are running
> 45 kernel, I presume you wouldn't need any livepatches as everything
> is rolled into the latest kernel update.
>
> --
> Regards,
>
> Dimitri.
>
>
>



-- 
Regards,

Dimitri.

-- 
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: canonical livepatch

[Dimitri John Ledkov]

Hello,

On 4 November 2016 at 09:00, Christian Ehrhardt
 wrote:
> Hi,
> just checked, with the same kernel mine still looks today like yours did
> initially.
> If run the status command with --verbose it will list the status it is in,
> which might help seeing whats going on on your system.
>

Well if you reboot every day, then you boot the kernel which is fully
patched - with all security (not just severe ones) and bugfixes. Such
kernels are released at the same time as livepatches.
I.e. if one can afford reboots, one is fully up to date.

Plus this service is currently running for xenial only.

I don't like rebooting my desktop. Hence I have:

$ uptime
 11:25:14 up 24 days,  7:20,  3 users,  load average: 3.15, 2.50, 2.20

$ lsmod | grep live
kpatch_livepatch_Ubuntu_4_4_0_38_57_generic_1349152  1

$ sudo canonical-livepatch status --verbose
client-version: "5"
machine-id: censored
machine-token: censored
architecture: x86_64
cpu-model: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz
last-check: 2016-11-04T11:07:47.882167806Z
boot-time: 2016-10-11T05:05:04+01:00
uptime: 583h20m17s
status:
- kernel: 4.4.0-38.57-generic
  running: true
  livepatch:
state: applied
version: "13.3"
fixes: ""

Maybe I should reboot into a newer kernel 38 -> 45. If you are running
45 kernel, I presume you wouldn't need any livepatches as everything
is rolled into the latest kernel update.

-- 
Regards,

Dimitri.

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

Bug#834718: choreonoid: maintainer address bounces

[Dimitri John Ledkov]

Hello,

On 1 November 2016 at 04:01, Adrian Bunk  wrote:
>
> On Thu, Aug 18, 2016 at 11:21:27AM +0200, Jakub Wilk wrote:
> > Source: choreonoid
> > Version: 1.5.0+dfsg-0.1
> > Severity: serious
> > Justification: Policy §3.3
> >
> > I tried to report a bug against this package, and I got:
> >
> > > Your mail to 'Ubuntu-devel-discuss' with the subject
> > >
> > >Bug#834715: libcnoid-dev: arch-dependent file in "Multi-Arch: same"
> > > package
> > >
> > > Is being held until the list moderator can review it for approval.
> > >
> > > The reason it is being held:
> > >
> > >Post by non-member to a members-only list
> >
> > As per Policy §3.3: “The email address given in the ‘Maintainer’ control
> > field must accept mail from those role accounts in Debian used to send
> > automated mails regarding the package. This includes non-spam mail from the
> > bug-tracking system, […].”
> >
> > NB, this is caught by Lintian:
> >
> > E: choreonoid source: maintainer-address-causes-mail-loops-or-bounces 
> > Ubuntu Developers 
>
>
> Maintainer: Ubuntu Developers 
> Original-Maintainer: Thomas Moulard 
>
>
> Dimitri, did you accidentally include this maintainer change typical
> for Ubuntu in your NMU?
>

Indeed this is bonkers. My bad. I guess I included this by accident,
when reuploading a fix from ubuntu to debian.

>
> > Jakub Wilk
>
> cu
> Adrian
>
> --
>
>"Is there not promise of rain?" Ling Tan asked suddenly out
> of the darkness. There had been need of rain for many days.
>"Only a promise," Lao Er said.
>Pearl S. Buck - Dragon Seed
>



-- 
Regards,

Dimitri.

-- 
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: Generating a new ubuntu-keyring .deb to sign ISO CD

[Dimitri John Ledkov]

On 25 October 2016 at 21:56, Stefani Seibold <stef...@seibold.net> wrote:
> Am Dienstag, den 25.10.2016, 14:35 +0100 schrieb Dimitri John Ledkov:
>> On 25 October 2016 at 14:15, Stefani Seibold <stef...@seibold.net>
>> wrote:
>> >
>> > On 25 October 2016 at 12:00, Stefani Seibold <stef...@seibold.net>
>> > >
>> > > wrote:
>> > > >
>> > > >
>> > > > Hi,
>> > > >
>> > > > i want modify an existing ubuntu 16.10 iso image to provide a
>> > > > new
>> > > > kernel for a server device which is currently in development
>> > > > and
>> > > > yet
>> > > > not on the market.
>> > > >
>> > > > I trying to build a new ubuntu-keyring.deb to sign my modified
>> > > > packages
>> > > > in the ISO Image. I followed the instructions provided by
>> > > > Ubuntu  (http
>> > > > s://help.ubuntu.com/community/InstallCDCustomization), but
>> > > > without
>> > > > success.
>> > > >
>> > > > When i follow the instructions in the chapter "Generating a new
>> > > > ubuntu-
>> > > > keyring .deb to sign your CD" i get a lot off errors:
>> > > >
>> > > > dpkg-buildpackage -rfakeroot -m"Myname <myn...@myhost.net>"
>> > > > -k7F6D4417D881EFC3E7FA02E636F2F7B4F8A2CAC9
>> > > > dpkg-buildpackage: info: source package ubuntu-keyring
>> > > > dpkg-buildpackage: info: source version 2016.09.19
>> > > > dpkg-buildpackage: info: source distribution yakkety
>> > > > dpkg-buildpackage: info: host architecture amd64
>> > > >  dpkg-source --before-build ubuntu-keyring-2016.09.19
>> > > >  fakeroot debian/rules clean
>> > > > test -f keyrings/ubuntu-archive-keyring.gpg
>> > > > rm -f foo foo.asc *.bak *~ */*~ debian/files* debian/*substvars
>> > > > rm -rf debian/tmp debian/ubuntu-keyring-udeb
>> > > >  dpkg-source -b ubuntu-keyring-2016.09.19
>> > > > dpkg-source: warning: no source format specified in
>> > > > debian/source/format, see dpkg-source(1)
>> > > > dpkg-source: info: using source format '1.0'
>> > > > dpkg-source: info: building ubuntu-keyring in ubuntu-
>> > > > keyring_2016.09.19.tar.gz
>> > > > dpkg-source: info: building ubuntu-keyring in ubuntu-
>> > > > keyring_2016.09.19.dsc
>> > > >  debian/rules build
>> > > > make: Nothing to be done for 'build'.
>> > > >  fakeroot debian/rules binary
>> > > > test -f keyrings/ubuntu-archive-keyring.gpg
>> > > > test root = "`whoami`"
>> > > > gpg --no-default-keyring --keyring /usr/share/keyrings/debian-
>> > > > keyring.gpg --decrypt SHA512SUMS.txt.asc | sha512sum -c -
>> > > > gpg: Signature made Mon Sep 19 19:22:17 2016 CEST
>> > > > gpg:using RSA key CAC2D8B9CD2CA5F9
>> > > > keyrings/ubuntu-archive-keyring.gpg: OK
>> > > > keyrings/ubuntu-archive-removed-keys.gpg: OK
>> > > > keyrings/ubuntu-keyring-2004-archive.gpg: OK
>> > > > keyrings/ubuntu-keyring-2004-cdimage.gpg: OK
>> > > > keyrings/ubuntu-keyring-2012-archive.gpg: OK
>> > > > keyrings/ubuntu-keyring-2012-cdimage.gpg: OK
>> > > > keyrings/ubuntu-master-keyring.gpg: OK
>> > > > gpg: BAD signature from "Dimitri John Ledkov <x...@ubuntu.com>"
>> > > > [unknown]
>> > > > gpg --no-default-keyring --keyring /usr/share/keyrings/debian-
>> > > > keyring.gpg --decrypt md5sums.txt | md5sum -c -
>> > > > gpg: Signature made Sat May 19 03:30:13 2012 CEST
>> > > > gpg:using RSA key 393587D97D86500B
>> > > > keyrings/ubuntu-archive-keyring.gpg: FAILED
>> > > > gpg: Good signature from "Colin Watson <cjwatson@chiark.greenen
>> > > > d.or
>> > > > g.uk>" [unknown]
>> > > > gpg: aka "Colin Watson <cjwat...@debian.org>"
>> > > > [unknown]
>> > > > gpg: aka "Colin Watson <cjwat...@ubuntu.com>"
>> > > > [unknown]
>> > > > gpg: aka "Colin Watson <cjwat...@canonical.com>
>> > > > "
>>

Re: Generating a new ubuntu-keyring .deb to sign ISO CD

[Dimitri John Ledkov]

On 25 October 2016 at 14:15, Stefani Seibold <stef...@seibold.net> wrote:
> On 25 October 2016 at 12:00, Stefani Seibold <stef...@seibold.net>
>> wrote:
>> >
>> > Hi,
>> >
>> > i want modify an existing ubuntu 16.10 iso image to provide a new
>> > kernel for a server device which is currently in development and
>> > yet
>> > not on the market.
>> >
>> > I trying to build a new ubuntu-keyring.deb to sign my modified
>> > packages
>> > in the ISO Image. I followed the instructions provided by
>> > Ubuntu  (http
>> > s://help.ubuntu.com/community/InstallCDCustomization), but without
>> > success.
>> >
>> > When i follow the instructions in the chapter "Generating a new
>> > ubuntu-
>> > keyring .deb to sign your CD" i get a lot off errors:
>> >
>> > dpkg-buildpackage -rfakeroot -m"Myname <myn...@myhost.net>"
>> > -k7F6D4417D881EFC3E7FA02E636F2F7B4F8A2CAC9
>> > dpkg-buildpackage: info: source package ubuntu-keyring
>> > dpkg-buildpackage: info: source version 2016.09.19
>> > dpkg-buildpackage: info: source distribution yakkety
>> > dpkg-buildpackage: info: host architecture amd64
>> >  dpkg-source --before-build ubuntu-keyring-2016.09.19
>> >  fakeroot debian/rules clean
>> > test -f keyrings/ubuntu-archive-keyring.gpg
>> > rm -f foo foo.asc *.bak *~ */*~ debian/files* debian/*substvars
>> > rm -rf debian/tmp debian/ubuntu-keyring-udeb
>> >  dpkg-source -b ubuntu-keyring-2016.09.19
>> > dpkg-source: warning: no source format specified in
>> > debian/source/format, see dpkg-source(1)
>> > dpkg-source: info: using source format '1.0'
>> > dpkg-source: info: building ubuntu-keyring in ubuntu-
>> > keyring_2016.09.19.tar.gz
>> > dpkg-source: info: building ubuntu-keyring in ubuntu-
>> > keyring_2016.09.19.dsc
>> >  debian/rules build
>> > make: Nothing to be done for 'build'.
>> >  fakeroot debian/rules binary
>> > test -f keyrings/ubuntu-archive-keyring.gpg
>> > test root = "`whoami`"
>> > gpg --no-default-keyring --keyring /usr/share/keyrings/debian-
>> > keyring.gpg --decrypt SHA512SUMS.txt.asc | sha512sum -c -
>> > gpg: Signature made Mon Sep 19 19:22:17 2016 CEST
>> > gpg:using RSA key CAC2D8B9CD2CA5F9
>> > keyrings/ubuntu-archive-keyring.gpg: OK
>> > keyrings/ubuntu-archive-removed-keys.gpg: OK
>> > keyrings/ubuntu-keyring-2004-archive.gpg: OK
>> > keyrings/ubuntu-keyring-2004-cdimage.gpg: OK
>> > keyrings/ubuntu-keyring-2012-archive.gpg: OK
>> > keyrings/ubuntu-keyring-2012-cdimage.gpg: OK
>> > keyrings/ubuntu-master-keyring.gpg: OK
>> > gpg: BAD signature from "Dimitri John Ledkov <x...@ubuntu.com>"
>> > [unknown]
>> > gpg --no-default-keyring --keyring /usr/share/keyrings/debian-
>> > keyring.gpg --decrypt md5sums.txt | md5sum -c -
>> > gpg: Signature made Sat May 19 03:30:13 2012 CEST
>> > gpg:using RSA key 393587D97D86500B
>> > keyrings/ubuntu-archive-keyring.gpg: FAILED
>> > gpg: Good signature from "Colin Watson <cjwat...@chiark.greenend.or
>> > g.uk>" [unknown]
>> > gpg: aka "Colin Watson <cjwat...@debian.org>"
>> > [unknown]
>> > gpg: aka "Colin Watson <cjwat...@ubuntu.com>"
>> > [unknown]
>> > gpg: aka "Colin Watson <cjwat...@canonical.com>"
>> > [unknown]
>> > gpg: WARNING: This key is not certified with a trusted signature!
>> > gpg:  There is no indication that the signature belongs to
>> > the owner.
>> > Primary key fingerprint: AC0A 4FF1 2611 B6FC CF01  C111 3935 87D9
>> > 7D86 500B
>> > md5sum: WARNING: 1 computed checksum did NOT match
>> > debian/rules:92: recipe for target 'checkkeyrings' failed
>> > make: *** [checkkeyrings] Error 1
>> > dpkg-buildpackage: error: fakeroot debian/rules binary gave error
>> > exit status 2
>> >
>> > Any idea? Is there a instruction manual or a how to which gives me
>> > detailed instructions how i can modify an existing iso image?
>> >
>> > I am not sure it this is the right mailing list for my question,
>> > please
>> > feel free to tell me the right one ;-)
>> >
>>
>> I added these extra validation checks in the ubuntu-keyring package
>> to
>

Re: Generating a new ubuntu-keyring .deb to sign ISO CD

[Dimitri John Ledkov]

On 25 October 2016 at 12:00, Stefani Seibold <stef...@seibold.net> wrote:
> Hi,
>
> i want modify an existing ubuntu 16.10 iso image to provide a new
> kernel for a server device which is currently in development and yet
> not on the market.
>
> I trying to build a new ubuntu-keyring.deb to sign my modified packages
> in the ISO Image. I followed the instructions provided by Ubuntu  (http
> s://help.ubuntu.com/community/InstallCDCustomization), but without
> success.
>
> When i follow the instructions in the chapter "Generating a new ubuntu-
> keyring .deb to sign your CD" i get a lot off errors:
>
> dpkg-buildpackage -rfakeroot -m"Myname <myn...@myhost.net>" 
> -k7F6D4417D881EFC3E7FA02E636F2F7B4F8A2CAC9
> dpkg-buildpackage: info: source package ubuntu-keyring
> dpkg-buildpackage: info: source version 2016.09.19
> dpkg-buildpackage: info: source distribution yakkety
> dpkg-buildpackage: info: host architecture amd64
>  dpkg-source --before-build ubuntu-keyring-2016.09.19
>  fakeroot debian/rules clean
> test -f keyrings/ubuntu-archive-keyring.gpg
> rm -f foo foo.asc *.bak *~ */*~ debian/files* debian/*substvars
> rm -rf debian/tmp debian/ubuntu-keyring-udeb
>  dpkg-source -b ubuntu-keyring-2016.09.19
> dpkg-source: warning: no source format specified in debian/source/format, see 
> dpkg-source(1)
> dpkg-source: info: using source format '1.0'
> dpkg-source: info: building ubuntu-keyring in ubuntu-keyring_2016.09.19.tar.gz
> dpkg-source: info: building ubuntu-keyring in ubuntu-keyring_2016.09.19.dsc
>  debian/rules build
> make: Nothing to be done for 'build'.
>  fakeroot debian/rules binary
> test -f keyrings/ubuntu-archive-keyring.gpg
> test root = "`whoami`"
> gpg --no-default-keyring --keyring /usr/share/keyrings/debian-keyring.gpg 
> --decrypt SHA512SUMS.txt.asc | sha512sum -c -
> gpg: Signature made Mon Sep 19 19:22:17 2016 CEST
> gpg:using RSA key CAC2D8B9CD2CA5F9
> keyrings/ubuntu-archive-keyring.gpg: OK
> keyrings/ubuntu-archive-removed-keys.gpg: OK
> keyrings/ubuntu-keyring-2004-archive.gpg: OK
> keyrings/ubuntu-keyring-2004-cdimage.gpg: OK
> keyrings/ubuntu-keyring-2012-archive.gpg: OK
> keyrings/ubuntu-keyring-2012-cdimage.gpg: OK
> keyrings/ubuntu-master-keyring.gpg: OK
> gpg: BAD signature from "Dimitri John Ledkov <x...@ubuntu.com>" [unknown]
> gpg --no-default-keyring --keyring /usr/share/keyrings/debian-keyring.gpg 
> --decrypt md5sums.txt | md5sum -c -
> gpg: Signature made Sat May 19 03:30:13 2012 CEST
> gpg:using RSA key 393587D97D86500B
> keyrings/ubuntu-archive-keyring.gpg: FAILED
> gpg: Good signature from "Colin Watson <cjwat...@chiark.greenend.org.uk>" 
> [unknown]
> gpg: aka "Colin Watson <cjwat...@debian.org>" [unknown]
> gpg: aka "Colin Watson <cjwat...@ubuntu.com>" [unknown]
> gpg: aka "Colin Watson <cjwat...@canonical.com>" [unknown]
> gpg: WARNING: This key is not certified with a trusted signature!
> gpg:  There is no indication that the signature belongs to the owner.
> Primary key fingerprint: AC0A 4FF1 2611 B6FC CF01  C111 3935 87D9 7D86 500B
> md5sum: WARNING: 1 computed checksum did NOT match
> debian/rules:92: recipe for target 'checkkeyrings' failed
> make: *** [checkkeyrings] Error 1
> dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 
> 2
>
> Any idea? Is there a instruction manual or a how to which gives me
> detailed instructions how i can modify an existing iso image?
>
> I am not sure it this is the right mailing list for my question, please
> feel free to tell me the right one ;-)
>

I added these extra validation checks in the ubuntu-keyring package to
make sure that signing keys are not modified by accident, and to make
sure that checksums are signed by semi known-to-be-good keys.

To bypass these checks comment out commands under the "checkkeyrings:" target.

NB! Do make sure you ship your key as a key fragment in
/etc/apt/trusted.gpg.d/ as apt-key is no longer called, and from
yakkety and up signing keys must be shipped as individually exported
keys in /etc/apt/trusted.gpg.d directory.

Ideally d-i would support key fragments just like installed systems
can, then one wouldn't need to rebuild ubuntu-keyring at all.

-- 
Regards,

Dimitri.

-- 
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: Installation Media and supportability of i386 in 18.04 LTS Re: Ubuntu Desktop on i386

[Dimitri John Ledkov]

Hello Mark,

On 29 June 2016 at 14:37, Mark Shuttleworth  wrote:
>
> Folks, I think we need to understand whether i386 won't be widely used
> for very small IoT devices and hence be important for developers
> targeting those. I accept i386 i no longer relevant for PC's and
> laptops, but I would not be surprised if 32-bit x86 is used in small
> 'embedded' environments. Please factor this in to the discussion, and
> let's circle back to review once there is an assessment that includes
> that insight.
>

Indeed. I believe we will continue to have 32-bit x86 port in 18.04
LTS and we will continue to asses which subsets of it are reasonable
to support and ship in various form factors.

Looking at the SoC and Embedded CPU product lines from Intel (Atom and
launched SoFIA), AMD, VIA - they are all 64-bit capable CPUs.

Is the choice to go i386 there is not due CPU capabilities, but due to
memory constraints?

I think it might make sense to investigate if we can optimise and
reduce our minimal required committed RAM usage on 64-bit, from fixing
software bugs to pulling tricks with compressed RAM and swap. If we
can hit low enough memory usage, a choice to use 64-bit will become
less of issue in such devices. And at the same time improve our
deployment density in the cloud scenarios.

Failing that, is there a sufficient demand in the embedded space for x32 port?

Above are some of the questions to resolve in the coming years.

-- 
Regards,

Dimitri.

-- 
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: Installation Media and supportability of i386 in 18.04 LTS Re: Ubuntu Desktop on i386

[Dimitri John Ledkov]

Hello,

On 28 June 2016 at 21:08, Seth Arnold  wrote:
>> 18.04 LTS:
>> * continue to provide i386 port to run legacy applications on amd64
>> * stop producing i386 d-i / netboot installer
>> * stop producing i386 kernel
>> * stop producing i386 cloud-images
>> * stop producing i386 ubuntu-desktop.iso
>> * stop producing i386 ubuntu-server.iso
>>
>> 18.10+:
>> * Stop providing i386 port
>> * Run legacy i386 only application in snaps / containers / virtual machines
>
> I'm afraid this proposal may strand some current i386 users on a release
> with no lifetime to it.
>
> 16.04's 32 bit support has a five-year lifespan. We may not be able to
> support the whole thing for the full five years but it should mostly work.
>
> But if we release 16.10, 17.04, 17.10 i386, we're basically encouraging
> users to install them and upgrade them and then find out in mid-2018 that
> they've reached the end of their OS life and no way back to the safety of
> 16.04 LTS.

My current hunch is like this at the moment:

- 18.04 to still have an i386 port in the archive, and be upgradable to.

- 18.04 not having desktop/server install media (however maybe even
releases before that)

- 18.04 has "ubuntu-desktop" but without security support

- 18.04 on i386 having a limited security support, driven only by
particular products if any are on the support timeline at the time

-- 
Regards,

Dimitri.

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

Installation Media and supportability of i386 in 18.04 LTS Re: Ubuntu Desktop on i386

[Dimitri John Ledkov]

Hello Bryan,

Let me resurrect this thread. In the context of what we should be
doing in 18.04 and what to do between now and then.

In 2018:
- it will be over 2 years since 3rd party ISVs stopped supporting
software on i386, or even never had it officially
- e.g. Google Chrome, ZFS, Docker, etc
- with both desktop and server software developed, tested and deployed
on amd64 only

And in 2018, the question will come if we can effectively provide
security support on i386.

Between now and 2018, it would be logical to limit amount of new
installations of i386, because cross-grading between i386->amd64 is
not something we can reliably ship.
We must continue provide the i386 port, to support multiarch and 3rd
party legacy application that are only available as i386 binaries.

Building i386 images is not "for free", it comes at the cost of
utilizing our build farm, QA and validation time. Whilst we have
scalable build-farms, i386 still requires all packages, autopackage
tests, and ISOs to be revalidated across our infrastructure. As well
as take up mirror space & bandwidth.

Thus the question is what can we and what should we do to limit i386
installations before they become unsupportable?

Here is an example draft plan to bikeshed over:

16.10, 17.04, 17.10:
* continue to provide i386 port to run legacy applications on amd64
* continue to build i386 d-i / netboot installer
* continue to build i386 kernel
* continue to build i386 cloud-images
* stop producing i386 ubuntu-desktop.iso
* stop producing i386 ubuntu-server.iso

18.04 LTS:
* continue to provide i386 port to run legacy applications on amd64
* stop producing i386 d-i / netboot installer
* stop producing i386 kernel
* stop producing i386 cloud-images
* stop producing i386 ubuntu-desktop.iso
* stop producing i386 ubuntu-server.iso

18.10+:
* Stop providing i386 port
* Run legacy i386 only application in snaps / containers / virtual machines

Or some other variation of above things and/or adjusted timelines.
What do you think is appropriate? Can we survey and/or somehow
validate if above would be appropriate or needs to be extended or can
be shortened?

The key point here is lack of upstream software support and upstream
security support on i386, rather than actual hardware being out of
stock and/or old.

In essence this would mean April 2021 as the sunset for i386 as the
host/base OS architecture. And April 2023 to run legacy i386
applications with security support.

Regards,

Dimitri.


On 2 February 2016 at 02:12, Bryan Quigley <bryan.quig...@canonical.com> wrote:
> The plan from the session we did over a year ago was:
> "Specifically the Ubuntu (x86_32) desktop CD will be moved to cdimage
> around opening of 16.10".   The argument is that it was easy to build
> the CD and it was cheap to do.  It would be a community build that
> wouldn't be promoted on the Ubuntu website or officially tested.
>
> It doesn't make sense to stop building the CD unless:
> * We make the unity packages x86_64 bit only (what's the point in
> having less easy to test latest 32-bit unity packages?)
> * We drop x86_32 bit kernel support (guessing not something to
> consider until after 18.04?)
>
> I think it also makes sense to see if other derivatives want to go
> x86_64-bit only like  maybe Kubuntu (like I believe project Neon
> targets just 64 bit).  At some point we are going to want drop x86_32
> kernel support and just have 32-bit compatibility libraries, but I
> don't know when that makes sense.
>
> Also, does Valve Steam product rely on i386 multiarch binaries?
> Yes, it does, but it also downloads it's own Steam runtime with it's
> own libraries.
>
> And Netflix - does that run on amd64-only without i386
> multiarch?  I believe that runs completely with libs if you use Google Chrome.
> Oh, and also Google Chrome is dropping Linux x86_32 bit support.
>
> I'm also happy to revisit my survey [2] and see where people are today.
>
> Thanks for bringing this up again!
> Bryan
>
> [1] https://blueprints.launchpad.net/ubuntu/+spec/development-1411-drop-x86-32
> [2] https://bryanquigley.com/crazy-ideas/32-bit-usage-survey-results
> [3] 
> http://summit.ubuntu.com/uos-1411/meeting/22353/when-should-we-stop-making-32-bit-images/
>
> On Mon, Feb 1, 2016 at 5:14 PM, Dimitri John Ledkov <x...@ubuntu.com> wrote:
>> Hello,
>>
>> Ubuntu has an i386 port which is fully supported.
>>
>> There a bunch of 3rd party applications that rely on the Multi-Arch
>> technology to support/use i386 binaries on amd64 (e.g. Skype from the
>> partner archive). BTW, can we ask Microsoft to publish native amd64
>> binaries, rather than those that rely on multi-arch i386? Also, does
>> Valve Steam product rely on i386 multiarch binaries? or is it fully
>> amd64? (and e.g. downloads/bundle

Re: Support status of nginx in Ubuntu 14.04LTS expired in Feburary 2015?

[Dimitri John Ledkov]

Hi,

On 25 April 2016 at 19:45, Andreas Wundsam
 wrote:
> Hello Ubuntu Maintainers,
>
> I was surprised to see that ubuntu-support-status shows the support of
> package nginx expired in February 2015?
>
> ---
> $ ubuntu-support-status --show-all
> []
> Supported until February 2015 (9m):
> [...] nginx nginx-common
> ---
>
> apt show shows the package as being in main, but receiving only 9 months of
> support:
>
> ---
> Supported: 9m
> APT-Sources: http://us.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages
> 
>
> So far, it has been my world view that packages that reside in the main
> repository would receive the full 5 years of LTS support.
>
> What am I missing?
>

To answer your question about Trusty however, nginx source package
builds some thing into main (with 5 years of security support) and
into universe (community security support only).

Main:
nginx, nginx-common, nginx-core, nginx-doc

Universe:
nginx-extras, nginx-full, nginx-light, nginx-naxsi, nginx-naxsi-ui

My understand is that nginx packages that are in main, should be in
the server supported seed and should have received Supported: 5 years
field. This is the case in xenial.

Looking at the package set changes, in xenial nginx correctly declares
"5 years" of support. Which seems to be due to this commit from
stgraber:

revno: 1978
committer: Stéphane Graber 
branch nick: platform.utopic
timestamp: Fri 2014-08-15 11:22:21 -0400
message:
  Move server stuff from ubuntu/supported

I guess we can do a similar commit for trusty, and then the supported
fields will be corrected in the -security/-updates pockets.

If server team agrees.

-- 
Regards,

Dimitri.

-- 
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: Unblock p7zip 9.20.1~dfsg.1-5 from xenial-proposed

[Dimitri John Ledkov]

It is not an SRU build, the build is for yakkety release. I simply did
it before we had a yakkety name.

On 22 April 2016 at 09:46, Amr Ibrahim  wrote:
> Now it builds, but it is still in xenial-proposed! Does it need to be
> approved by the SRU Verification team?
> --
> 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



-- 
Regards,

Dimitri.

-- 
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: Can we include HWE in the release version?

[Dimitri John Ledkov]

On 6 April 2016 at 22:25, Xen  wrote:
> Bryan Quigley schreef op 06-04-16 22:35:
>> Hi all,
>>
>> The naming scheme of just  "Ubuntu 14.04.4 LTS" is no longer
>> meaningful when it comes to determining what kernel/mesa/xorg you are
>> on.   It's also confusing to many users what 14.04.4 actually means
>> and it makes determining if you are supported more difficult [1].
>>
>> I propose for 16.04 we change it so that the HWE# is included in the
>> version, so it's trivial to determine the support level.
>>
>> So for example, if we had done this for 14.04 we would have releases like:
>> Ubuntu 14.04.4 LTS - Everyone up-to-date with stock kernel
>> Ubuntu 14.04.3 LTS HWE15.04 - Out of date with vivid kernel
>> Ubuntu 14.04.4 LTS HWE15.04 - Up-to-date with vivid kernel
>
> Personally I feel that naming scheme is hideous and will confuse even
> more people.
>
> What does HWE even mean? I can look it up, but it is not like it is some
> kind of well known acronym or abbreviation.
>
> (The way I understood it these point releases indeed brought new kernels
> in addition to something else. The confusion that I experienced was more
> the weird focus on end-of-support dates that was different for every
> point release, creating tiers of support that utterly confused me,
> particularly because the context with other (newer) versions of the
> distribution was not clear. The idea of point releases bringing new
> kernels and that "HWE" is not confusing at all. However, if this
> dramatically is going to change "end of support" dates, then suddenly it
> is not comprehensible anymore --- did it mean that a getting point
> release meant less support?
>
> What I remember is that the point releases had less support, which is
> not understandable because they are newer systems.
>
> Also if a point release actually means newer versions of all software
> this is confusing by itself. Creating the ability for new hardware is
> easy to understand. But if repos for .3 and .4 are going to be entirely
> different, and now you are going to create 2 dimensions: currency of
> software, and currency of kernel/HWE and you can mix them at will: that
> is not helpful.
>
> So I would suggest the confusion did not come from the naming scheme.
> The confusion came from the fact that these varying levels of support
> were incomprehensible. If anything upgrading to a newer kernel should be
> recommended and encouraged for the largest part and if anything that
> should give the benefit of longer support -- since you are up to date
> now, right?
>
> The fact that 14.04.1 is listed at end of life april 2019 and 14.04.2 is
> listed at august 2016 is just utterly confusing. Changing the naming is
> not going to help that.
>
> If these two components have different EOL you can just say so, I'm not
> sure if that is the case.
>
> So if you wanted some thoughts, my thought is that your proposal here
> would increase the confusion while not tackling the real issue.
>
> Regards.
>

LTS has 5 years of support.

There are multiple kernels available with full 5 year support:
- original (from .0 original release & .1 release)
- next-lts (from a .5 point release)

Intermediate releases backports:
- Available in .2; .3; .4
- Supported until .5 release which comes with next-LTS kernel
- Upgrade path is to the next LTS release, or to the .5 HWE stack

We do send EOL announcements for the HWE kernels. I do not believe we
automatically upgrade people from them to the .5 / next-LTS kernel,
maybe we should. (or i am wrong, and we totally do it).
However in practice, people who use/care about HWE kernels upgrade to
the next HWE stack and/or next LTS release quite rapidly.

Regards,

Dimitri.


>
>
>> etc
>>
>> This does mean we could decide to provide downloads for both (we do
>> have some demand for this):
>> Ubuntu 14.04.4 LTS (Stock kernel)
>> Ubuntu 14.04.4 LTS HWE1510 (Wily HWE)
>>
>> And now we can differentiate between them in the same way on the
>> download site as in an installed system.
>>
>> Thoughts?
>> Bryan
>>
>> [1] https://wiki.ubuntu.com/1204_HWE_EOL
>> [2] https://wiki.ubuntu.com/Releases
>>
>
> --
> 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

-- 
Regards,

Dimitri.

-- 
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: Can we include HWE in the release version?

[Dimitri John Ledkov]

On 6 April 2016 at 21:35, Bryan Quigley  wrote:
> Hi all,
>
> The naming scheme of just  "Ubuntu 14.04.4 LTS" is no longer
> meaningful when it comes to determining what kernel/mesa/xorg you are
> on.   It's also confusing to many users what 14.04.4 actually means
> and it makes determining if you are supported more difficult [1].
>
> I propose for 16.04 we change it so that the HWE# is included in the
> version, so it's trivial to determine the support level.
>
> So for example, if we had done this for 14.04 we would have releases like:
> Ubuntu 14.04.4 LTS - Everyone up-to-date with stock kernel
> Ubuntu 14.04.3 LTS HWE15.04 - Out of date with vivid kernel
> Ubuntu 14.04.4 LTS HWE15.04 - Up-to-date with vivid kernel
> etc
>
> This does mean we could decide to provide downloads for both (we do
> have some demand for this):
> Ubuntu 14.04.4 LTS (Stock kernel)
> Ubuntu 14.04.4 LTS HWE1510 (Wily HWE)
>
> And now we can differentiate between them in the same way on the
> download site as in an installed system.
>

I am not sure what problem you are trying to fix.

First of all point releases are only installation media, and not the
packages archive.

We do provide installation media for past point releases, each one
with different HWE packs on them. These are all available for download
and installation from.

In general, we do not move people to next HWE stack, it's a manual
action until upgrade to next LTS. And from packages archive point of
view, they are all supported and available from the
archive.ubuntu.com.

We do not provide snapshot archives for point releases, thus it is
simply a matter off "did you dist-upgrade to everything that's
available in -security & -updates", regardless of the HWE stack one is
running.

All stacks are supported, and in theory, from any stack one should be
able to dist-upgrade to the next LTS and get the new stock kernel. I
do not believe we roll people from one HWE to the next within an LTS
release, so it is simply a mater of which installation media was used,
and/or which HWE packs one chose to install afterwords.

For trusty, the intermediate hwe stacks will go out of support, after
16.04.1 is released and thus LTS -> LTS upgrades enabled, and the
expectation there is for people to upgrade to 16.04.1, and most people
will / do.

--
Regards,

Dimitri.

-- 
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: gpg 2

[Dimitri John Ledkov]

On 27 February 2016 at 12:15, Gianfranco Costamagna
 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hi, while this works beautifully (and thanks for that), upgrading
> stuff in a stable release, breaking something like gpg encryption for
> end users it so bad.
>
> I wish this happened in xenial, rather than in the already released wily
> .
> (I got my thunderbird+gpg broken, so I used plain gpg as fallback)
>

Thunderbird in Ubuntu follows thunderbird support cycle, and thus we
do push newer thunderbird upstream releases into stable distributions.

Sounds like such an update missed to add "Depends: gnupg2" gnupg2 has
been available since precise, in parallel with gnupg (gnupg1).

-- 
Regards,

Dimitri.

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

Archive Reorg Episode VII: Follow Build-Depends

[Dimitri John Ledkov]

tl;dr - xnox wants to remove 1 344 (35%) source packages from main

Google Doc for suggestions & comments:
https://docs.google.com/document/d/1dJBtLLCppH2yt664S8G2jB_tK-iWi_D7wqaN6S4ddwI/edit

Sample old/new germinate output is at:
http://people.canonical.com/~xnox/germinate-output/

---

= Archive Reorg Episode VII: Follow Build-Depends =

== Introduction ==

Loosely this builds up on the existing portions of the Archive Reorg
evolution. To recap, we have 4 components in the archive, which are
defined by their licensing on one axis, and based on seeds for the
other axis. Thus e.g. sufficiently free packages, that are seeded in
specific products are published in main component.

Over the years, the structure, processes and permissions of the
archive have evolved. And today we have a spectrum of upload rights,
at per-package, per-seed, per-packageset, per-component and all-in-one
core-dev. We have also been expanding our confidence in using universe
to test and validate main. For example, autopkgtest are executed
archive-wide without main/universe segregation and thus packages in
universe can catch and prevent release of broken packages in main. And
vice versa.

Similarly we have been using components in a flexible manner, e.g.
source packages in main can build binary packages that are published
in universe.


Currently, main is a closed set across three dpkg relationships:

 - Depends

 - Recommends (* with follow-depends feature, default for ubuntu-platform)

 - Pre-Depends

 - Built-Using (* not currently implemented but should have been)

 - Build-Depends[ -Arch | -Indep ]

With rigorous processes around these - e.g. seeds, germinate,
components-mismatches, MIR, etc.

This has caused a creep of technical debt, and high ongoing
maintenance. For example, to keep unsupported languages/runtimes out
of main, a permanent fork had to be established from Debian to split
the sources, and disable build dependencies. E.g. we have two
identical boost packages (one in main, one in universe) to keep
openmpi out of main. Similarly we have disabled pypy extensions of
many packages in main, to keep pypy in universe. Or even trivial
things like disabling building documentation (desired), due to
required tooling being unsuitable for seeding in main (undesired). In
effect this cripples Ubuntu in many ways, and generates extra and
potentially unnecessary work for Ubuntu developers.

== Proposal ==

I would like to propose to relax the requirement for build-depends of
packages in main to come from main only, and thus stop following
build-dependencies to be part of a closed set in main component.

This would mean that the universe component will always be available
to get build-dependencies. Main will remain a closed set of binary
packages dependencies, sources and built-using. This will enable
building, in a single pass, packages with testsuite or
optional/additional bindings that require universe build-dependencies
or will be published into universe anyway.

Some examples:

- boost can become one src package in main, with mpi portions built,
yet packaged/published into universe

- testsuite only dependencies can be used to run the full testsuite at
buildtime (e.g. automake has a plethora of things it wants to validate
in universe)

- documentation tooling can be pulled from universe to build
documentation, and ship the resultant static files in main (e.g. zsh)

- we can build pypy bindings for packages in main, and e.g. python2
may (in the future) drop to universe

This does not abolish the MIR process. If a hard binary dependency is
gained (e.g. shared linking), the binary and source package still must
go through MIR process and be published in main.

This scheme however creates new caveats, and potential for “static”
linking to leak from universe into main binaries:

- a C++ template only library, becomes available to be used as a
build-dependency, without going through main, or generating a
closed-set relationship of “depends”, or “recommends”.

- a statically linked library from universe, can end up in main.

- macros and other code in C header files from universe can end up in main

- bootstrap & complete build-dependencies chain may end up
exponentially growing, thus e.g. it may become harder to remove
obsolete universe packages

For these cases built-using should be used. And built-using should be
included in the main closed set.

== Technical changes and feasibility ==

To accomplish above the following changes would be required:

germinate

- add an option to [no]-follow-build-depends

- make sure “built-using” sources are followed

components-mismatches

- make sure “built-using” are included

launchpad

- enable “universe” component by default, per distroseries

== Feedback and Retrospective ==

Some may recall Archive Reorg Episode VI plans, which were drafted
years ago. This proposal is much smaller in scope, aiming to resolve
the build-dependencies issue as a stand alone quirk. This is a
technically small 

Re: Archive Reorg Episode VII: Follow Build-Depends

[Dimitri John Ledkov]

On 10 February 2016 at 21:14, Marc Deslauriers
<marc.deslauri...@canonical.com> wrote:
> On 2016-02-10 03:32 PM, Dimitri John Ledkov wrote:
>> tl;dr - xnox wants to remove 1 344 (35%) source packages from main
>
> What did you use to calculate that? I get 1 344 packages by using all.sources 
> in
> the germinate output, but all.sources also contains a lot of universe 
> packages.

A better output would have been from a sample components missmatches,
which I have failed to generate (that tried to like demote dash)

And looking at the bottom of:
http://people.canonical.com/~ubuntu-archive/component-mismatches.html

All of haskell and a bunch of other things are trying to enter main at
the moment. So it's hard to estimate things for xenial, given how much
is currently in-flux in it. with hundreds of things mismatched.

Maybe I should generate a sample comparison off wily?

>
>>
>> Google Doc for suggestions & comments:
>> https://docs.google.com/document/d/1dJBtLLCppH2yt664S8G2jB_tK-iWi_D7wqaN6S4ddwI/edit
>>
>> Sample old/new germinate output is at:
>> http://people.canonical.com/~xnox/germinate-output/
>>
>> ---
>>
>> = Archive Reorg Episode VII: Follow Build-Depends =
>>
>> == Introduction ==
>>
>> Loosely this builds up on the existing portions of the Archive Reorg
>> evolution. To recap, we have 4 components in the archive, which are
>> defined by their licensing on one axis, and based on seeds for the
>> other axis. Thus e.g. sufficiently free packages, that are seeded in
>> specific products are published in main component.
>>
>> Over the years, the structure, processes and permissions of the
>> archive have evolved. And today we have a spectrum of upload rights,
>> at per-package, per-seed, per-packageset, per-component and all-in-one
>> core-dev. We have also been expanding our confidence in using universe
>> to test and validate main. For example, autopkgtest are executed
>> archive-wide without main/universe segregation and thus packages in
>> universe can catch and prevent release of broken packages in main. And
>> vice versa.
>>
>> Similarly we have been using components in a flexible manner, e.g.
>> source packages in main can build binary packages that are published
>> in universe.
>>
>>
>> Currently, main is a closed set across three dpkg relationships:
>>
>>  - Depends
>>
>>  - Recommends (* with follow-depends feature, default for ubuntu-platform)
>>
>>  - Pre-Depends
>>
>>  - Built-Using (* not currently implemented but should have been)
>>
>>  - Build-Depends[ -Arch | -Indep ]
>>
>> With rigorous processes around these - e.g. seeds, germinate,
>> components-mismatches, MIR, etc.
>>
>> This has caused a creep of technical debt, and high ongoing
>> maintenance. For example, to keep unsupported languages/runtimes out
>> of main, a permanent fork had to be established from Debian to split
>> the sources, and disable build dependencies. E.g. we have two
>> identical boost packages (one in main, one in universe) to keep
>> openmpi out of main. Similarly we have disabled pypy extensions of
>> many packages in main, to keep pypy in universe. Or even trivial
>> things like disabling building documentation (desired), due to
>> required tooling being unsuitable for seeding in main (undesired). In
>> effect this cripples Ubuntu in many ways, and generates extra and
>> potentially unnecessary work for Ubuntu developers.
>>
>> == Proposal ==
>>
>> I would like to propose to relax the requirement for build-depends of
>> packages in main to come from main only, and thus stop following
>> build-dependencies to be part of a closed set in main component.
>>
>> This would mean that the universe component will always be available
>> to get build-dependencies. Main will remain a closed set of binary
>> packages dependencies, sources and built-using. This will enable
>> building, in a single pass, packages with testsuite or
>> optional/additional bindings that require universe build-dependencies
>> or will be published into universe anyway.
>>
>> Some examples:
>>
>> - boost can become one src package in main, with mpi portions built,
>> yet packaged/published into universe
>>
>> - testsuite only dependencies can be used to run the full testsuite at
>> buildtime (e.g. automake has a plethora of things it wants to validate
>> in universe)
>>
>> - documentation tooling can be pulled from universe to build
>> documentation, and ship the resultant static files in main (e.g. zsh)
&

Re: kmod package

[Dimitri John Ledkov]

On 4 February 2016 at 03:26, Stan Wong  wrote:
> Hi,
>
> I just realize kmod package are not compile with --xz and --zlib option.
>
>
> Reason is new kernel > 3.18 now support module compression and kmod need to
> know how to detect it in order to generate working module deps file.

kmod is used on installed system, with split /usr, and inside d-i.

there is zlib udeb, thus enabling zlib compression is mostly harmless.

there is no xz-udeb that i can see however.

Thus to enable both: xz-utils need a udeb first, then one can enable
compression in kmod.

-- 
Regards,

Dimitri.

-- 
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: Ubuntu Desktop on i386

[Dimitri John Ledkov]

Hi,

could you please drop the HWE enablement stack out of this?

HWE kernels were long provided before we started doing X/graphics
stack. And they are there to enable new/latest hardware only.
HWE kernels are needed on servers & clouds, it's not just desktop =)

Also, whilst there are still tiny instances cloud providers (e.g.
512MB and less of RAM) we will continue to ship i386 cloud images and
i386 kernels.
Desktop is only one product based on of the ubuntu kernel, and it
doesn't get to dictate support for other products =)

So really: dropping the archive, dropping kernel, dropper HWE is out
of scope for this discussions. These are here to stay. The
desktop-i386.iso however, is something that we can discuss.

The cost of: testing, validation, release, and bandwidth to mirror it
is IMHO large. And costs more than the benefit it will provide.

On 2 February 2016 at 17:26, Bryan Quigley  wrote:
>> Kernel support is a separate vector. E.g. in Debian it is common to
>> install 32-bit userspace with the 64-bit kernel. Thus using all the
>> CPU/kernel features, access all the memory, yet have lower memory
>> utilisation.
>
> Right, but depending on what we decide it will also impact how tested
> the HWE stack is on Unity.  Say we stop building the x86_32 image
> starting with 16.10.  Would backporting the x86_32 bit kernel from
> 16.10 to 16.04.2 HWE release still happen?
>

Out of scope for this thread.

>>> I'm also happy to revisit my survey [2] and see where people are today.
>>
>> I'm not sure it's about where people are, but rather where we want people to 
>> be.
>
> I mean I want us to just drop 32-bit kernels and images entirely and
> just keep 32 bit compat libraries.   But I also want to give lots of
> notice so the soonest I'd want to that would be after 18.04 at this
> point.
>

Out of scope for this thread.

>> My argument for dropping .iso, but keeping the packages/archive is as 
>> follows:
>>
>> * we would like to support upgrades, for those that have 32 bit install
>>
>> * but we would like to prevent any new installations
>
> I just want to prevent further bit root for those upgrade users.
> There will be even less people testing those now, so I do think we
> need a plan to eventually remove Unity from the archive and maybe
> migrate those users to another DE?  (Unity8 seems to be doing x86_32
> releases? the obvious choice for me would be Xubuntu/Mate/Lubuntu but
> we don't need where to move today)
>

No need to provide upgrade path. The hardware will simply EOL.

>>
>> * because any new installation is amd64 capable, or such is the Ubuntu
>> Desktop ISO installer requirement for 16.04 LTS
>>
>> * reduce releases.ubuntu.com mirror costs by about a third
>>
>> Otherwise, all survey results will remain constant.
>>
>> Building images is cheap, however I do not believe we can actually
>> adequately support i386 ones for ubuntu desktop:
>>
>> * there is no i386-only certified hardware
>> * image manual testing has a cost
>> * no ubuntu developers use them =)
>>
>> Could we start the sunset period with removing flavour dropdown from
>> the ubuntu desktop download pages for 16.04? (But keep the i386 images
>> on releases.ubuntu.com?)
> I'm 100% for that.  Still supported (although not certified), but you
> really have to know you want to get it.
>
> So maybe a basic plan like:
> 1.  Announce that Ubuntu 16.04 LTS will be the last officially
> supported release of Unity.  Keep it on releases.u.c but remove from
> main download page.  Also announce that x86_32-bit Ubuntu (server
> too?) won't be getting HWE?

server is out of scope for this discussion, HWE is out of scope. I
don't think we ever announce any ubuntu.com website changes. And the
website has links to reach to reach the releases.u.c and cdimage.u.c
anyway.

> 2.  Drop to cdimage for 16.10 with not tested/supported caveat
> (continue based on usage numbers)

Ack.

> 3.  For 17.04 evaluate migration options and consider dropping Unity7
> from x86_32 archive

I'd rather say, no action. Reinstall is the best way to "upgrade"
those machines to a different ubuntu flavor, or like buy a new
hardware.

> 4.  For 18.04 have migration options well tested for 16.04 upgraders.
>

Well, not produce desktop i386 image. Would be an action here.

-- 
Regards,

Dimitri.

-- 
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: Ubuntu Desktop on i386

[Dimitri John Ledkov]

Hello,

Any change that desyncs things across architectures is active work and effort.

If i386 desktop images are produced, they will be produced exactly the
same way they were produced to date.

Spinning up point releases with or without hwe stack, was not per
architecture so far, but could be modified at point release time.

Regards,

Dimitri.


On 2 February 2016 at 19:03, Bryan Quigley <bryan.quig...@canonical.com> wrote:
> On Tue, Feb 2, 2016 at 1:28 PM, Dimitri John Ledkov <x...@ubuntu.com> wrote:
>> Hi,
>>
>> could you please drop the HWE enablement stack out of this?
>
> Hmm.. Let me make it clearer and drop a lot of it.
>
>> The cost of: testing, validation, release, and bandwidth to mirror it
>> is IMHO large. And costs more than the benefit it will provide.
> Agreed.
>
>>
>> On 2 February 2016 at 17:26, Bryan Quigley <bryan.quig...@canonical.com> 
>> wrote:
>>>> Kernel support is a separate vector. E.g. in Debian it is common to
>>>> install 32-bit userspace with the 64-bit kernel. Thus using all the
>>>> CPU/kernel features, access all the memory, yet have lower memory
>>>> utilisation.
>>>
>>> Right, but depending on what we decide it will also impact how tested
>>> the HWE stack is on Unity.  Say we stop building the x86_32 image
>>> starting with 16.10.  Would backporting the x86_32 bit kernel from
>>> 16.10 to 16.04.2 HWE release still happen?
>>>
>>
>> Out of scope for this thread.
>
> I disagree.. .let me reprase.
>
> If we build Ubuntu 16.04 LTS  x86_32 Desktop image will we update it
> with the HWE stack from 16.10/17.04/17.10/18.04 at the point releases
> (16.04.2) like usual?
>
> I'm not saying that other desktops (Like Kubuntu, and Unity x86_64)
> will still get the HWE like normal.  Just will we respin the 32-bit
> Unity CD?
>
>>>> My argument for dropping .iso, but keeping the packages/archive is as 
>>>> follows:
>>>>
>>>> * we would like to support upgrades, for those that have 32 bit install
>>>>
>>>> * but we would like to prevent any new installations
>>>
>>> I just want to prevent further bit root for those upgrade users.
>>> There will be even less people testing those now, so I do think we
>>> need a plan to eventually remove Unity from the archive and maybe
>>> migrate those users to another DE?  (Unity8 seems to be doing x86_32
>>> releases? the obvious choice for me would be Xubuntu/Mate/Lubuntu but
>>> we don't need where to move today)
>>>
>>
>> No need to provide upgrade path. The hardware will simply EOL.
>
> What do you mean by that exactly?
>
> Is this with us eventually dropping Unity7 from archive?  We still
> need to take some action even if it's just saying.. Sorry Ubuntu
> x86_32 with Unity can't be upgraded any further.  But then I don't see
> the harm in saying click here to install Desktop Environment X.
>
>>>>
>>>> * because any new installation is amd64 capable, or such is the Ubuntu
>>>> Desktop ISO installer requirement for 16.04 LTS
>>>>
>>>> * reduce releases.ubuntu.com mirror costs by about a third
>>>>
>>>> Otherwise, all survey results will remain constant.
>>>>
>>>> Building images is cheap, however I do not believe we can actually
>>>> adequately support i386 ones for ubuntu desktop:
>>>>
>>>> * there is no i386-only certified hardware
>>>> * image manual testing has a cost
>>>> * no ubuntu developers use them =)
>>>>
>>>> Could we start the sunset period with removing flavour dropdown from
>>>> the ubuntu desktop download pages for 16.04? (But keep the i386 images
>>>> on releases.ubuntu.com?)
>>> I'm 100% for that.  Still supported (although not certified), but you
>>> really have to know you want to get it.
>>>
>>> So maybe a basic plan like:
>>> 1.  Announce that Ubuntu 16.04 LTS will be the last officially
>>> supported release of Unity.  Keep it on releases.u.c but remove from
>>> main download page.  Also announce that x86_32-bit Ubuntu (server
>>> too?) won't be getting HWE?
>>
>> server is out of scope for this discussion, HWE is out of scope. I
>> don't think we ever announce any ubuntu.com website changes. And the
>> website has links to reach to reach the releases.u.c and cdimage.u.c
>> anyway.
>
> I meant to announce in the schedule/release notes the plan for the
> x86_32 release.  Last LTS with x86_32 Un

Re: Ubuntu Desktop on i386

[Dimitri John Ledkov]

On 2 February 2016 at 03:12, Bryan Quigley <bryan.quig...@canonical.com> wrote:
> The plan from the session we did over a year ago was:
> "Specifically the Ubuntu (x86_32) desktop CD will be moved to cdimage
> around opening of 16.10".   The argument is that it was easy to build
> the CD and it was cheap to do.  It would be a community build that
> wouldn't be promoted on the Ubuntu website or officially tested.
>
> It doesn't make sense to stop building the CD unless:
> * We make the unity packages x86_64 bit only (what's the point in
> having less easy to test latest 32-bit unity packages?)
> * We drop x86_32 bit kernel support (guessing not something to
> consider until after 18.04?)
>

Kernel support is a separate vector. E.g. in Debian it is common to
install 32-bit userspace with the 64-bit kernel. Thus using all the
CPU/kernel features, access all the memory, yet have lower memory
utilisation.

> I think it also makes sense to see if other derivatives want to go
> x86_64-bit only like  maybe Kubuntu (like I believe project Neon
> targets just 64 bit).  At some point we are going to want drop x86_32
> kernel support and just have 32-bit compatibility libraries, but I
> don't know when that makes sense.
>
> Also, does Valve Steam product rely on i386 multiarch binaries?
> Yes, it does, but it also downloads it's own Steam runtime with it's
> own libraries.
>
> And Netflix - does that run on amd64-only without i386
> multiarch?  I believe that runs completely with libs if you use Google Chrome.
> Oh, and also Google Chrome is dropping Linux x86_32 bit support.
>
> I'm also happy to revisit my survey [2] and see where people are today.
>

I'm not sure it's about where people are, but rather where we want people to be.

My argument for dropping .iso, but keeping the packages/archive is as follows:

* we would like to support upgrades, for those that have 32 bit install

* but we would like to prevent any new installations

* because any new installation is amd64 capable, or such is the Ubuntu
Desktop ISO installer requirement for 16.04 LTS

* reduce releases.ubuntu.com mirror costs by about a third

Otherwise, all survey results will remain constant.

Building images is cheap, however I do not believe we can actually
adequately support i386 ones for ubuntu desktop:

* there is no i386-only certified hardware
* image manual testing has a cost
* no ubuntu developers use them =)

Could we start the sunset period with removing flavour dropdown from
the ubuntu desktop download pages for 16.04? (But keep the i386 images
on releases.ubuntu.com?)

http://www.ubuntu.com/download/desktop

It has been switched to amd64 by default some time ago.

Regards,

Dimitri.

> Thanks for bringing this up again!
> Bryan
>
> [1] https://blueprints.launchpad.net/ubuntu/+spec/development-1411-drop-x86-32
> [2] https://bryanquigley.com/crazy-ideas/32-bit-usage-survey-results
> [3] 
> http://summit.ubuntu.com/uos-1411/meeting/22353/when-should-we-stop-making-32-bit-images/
>
> On Mon, Feb 1, 2016 at 5:14 PM, Dimitri John Ledkov <x...@ubuntu.com> wrote:
>> Hello,
>>
>> Ubuntu has an i386 port which is fully supported.
>>
>> There a bunch of 3rd party applications that rely on the Multi-Arch
>> technology to support/use i386 binaries on amd64 (e.g. Skype from the
>> partner archive). BTW, can we ask Microsoft to publish native amd64
>> binaries, rather than those that rely on multi-arch i386? Also, does
>> Valve Steam product rely on i386 multiarch binaries? or is it fully
>> amd64? (and e.g. downloads/bundles/ships any required i386 binaries
>> that it needs)? And Netflix - does that run on amd64-only without i386
>> multiarch?
>>
>> However, it seems to me that this is done specifically on otherwise
>> full amd64 installations.
>>
>> My guess is that: all currently shipped hardware, with enough support
>> to run full Unity (7) Desktop, is amd64. Tested with amd64 kernel, and
>> amd64 graphics drivers. And hardware validation is done on amd64 too.
>>
>> In 2016, people with i386-only hardware are unlikely to be capable to
>> run Unity 7 Desktop, and probably run other Ubuntu variants.  I guess
>> there are some accidental i386 users, e.g. those that have installed
>> i386 variant on amd64 hardware.
>>
>> Does it still make sense to build ubuntu-desktop-i386.iso? Validate
>> it? Test it on amd64 hardware? Ship it?
>>
>> To me this seems like a futile effort. Imho, we should only test the
>> relevant multiarch i386 pieces that are there to support 3rd-party,
>> i386-only apps on amd64 desktop.
>>
>> This is specifically about building, validating and shipping
>> ubuntu-desktop-i386.iso, specifical

Re: Wishes for +Xenial

[Dimitri John Ledkov]

RC bug would be one:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=749661

On 28 January 2016 at 20:31, Martinx - ジェームズ  wrote:
> BTW, do you know why ifuse was removed from Debian testing?
>
> On 28 January 2016 at 18:30, Martinx - ジェームズ  
> wrote:
>> Good point! ifuse 1.1.3 is not even on Debian! Look:
>>
>> http://tracker.debian.org/pkg/ifuse
>>
>> Ubuntu only have it on Universe repo, I think that it is importante to
>> move it to Main.
>>
>> For sure Xenial must have 1.1.3...
>>
>> On 28 January 2016 at 16:51, Mike M  wrote:
>>> Did anyone see my post on bumping ifuse to 1.1.3 to fix iOS mounting?  ;)
>>>
>>> -Mike
>>>
>>>
 On 23 January 2016 at 22:56, Martinx - ジェームズ 
 wrote:
>
> Hey guys,
>
>   I'm wondering here about what package versions we'll have on Xenial
> 16.04...
>
>   So, I'm creating a wish list!:-P
>
>>>
>>> --
>>> 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
>
> --
> 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



-- 
Regards,

Dimitri.

-- 
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: Disabling deb-src by default

[Dimitri John Ledkov]

Hello,

On 28 January 2016 at 10:49, Matthew Paul Thomas  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Usama Akkad wrote on 28/01/16 08:38:
>>
>> Source packages are enabled by default. I've commented the deb-src
>> line from my sources.list file and that saved the update servers
>> 16 hit (out of 87) when doing apt-get update One of the package for
>> the sources of the universe repository was 7 MB.
>>
>> ...
>
> "Default sources.list file has source packages enabled by default"
> 
>
> Maybe someone will fix this bug before its tenth birthday.
>
> I've catalogued other ways to speed up software updates.
> 

Hehe, I have giggled at:

Stop issuing “no-change rebuild” updates.

In actual fact the wording is misleading. The source code of _this_
package did not change, however one of the library dependencies have
changed ABI and thus a rebuild is required against the new library to
keep the package in question (a) installable (b) working. It's a
necessary evil, and it's not pointless =)

But i guess we should word our changelogs better somehow

-- 
Regards,

Dimitri.

-- 
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: Disabling deb-src by default

[Dimitri John Ledkov]

On 28 January 2016 at 20:48, Bryan Quigley  wrote:
> On Thu, Jan 28, 2016 at 3:52 AM, Martin Pitt  wrote:
>> Usama Akkad [2016-01-28 10:38 +0200]:
>>> Source packages are enabled by default.
>>
>> We don't enable them by default on cloud images, so I guess it can't
>> be a legal requirement to have them.
>
> I've always been a little confused by cloud images in that regard.
>
> On first boot:
> $apt-get source firefox
> ...E: You must put some 'source' URIs in your sources.list
>
> After one apt-get update:
> It works fine, they were in the sources the whole time.

Hm. can you paste sources.list in question? I wonder if it is
something silly like release pocket disabled, yet security deb-src
enabled. And hence one "gets" the security update source package. Or
some such.

Or simply the downloaded lists are purged, after update, when the
image is prepared.

Also, I do not doubt that you know how to fetch ubuntu sources =)

-- 
Regards,

Dimitri.

-- 
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: Re: about upstart

[Dimitri John Ledkov]

Hi,

You have asked a lot of questions already. Could you maybe elaborate
what are you investigating overall? Or what are you trying to achieve?
Answering questions one by one is not very productive.

UPSTART_SESSION variable points at private unix socket that one can
use to communicate with a user session upstart. When present in the
environment, initctl and other tools use that socket to talk to the
user upstart session.

Regards,

Dimitri.

On 8 January 2016 at 01:55, yan...@iscas.ac.cn  wrote:
>
>
> Where is the definition of environment variable "UPSTART_SESSION"
>
>
> From: Martin Pitt
> Date: 2016-01-07 17:54
> To: yan...@iscas.ac.cn
> CC: ubuntu-devel-discuss
> Subject: Re: Re: about upstart
> yan...@iscas.ac.cn [2016-01-07 15:20 +0800]:
>> How does ubuntu solve the the problem “initctl can not use when
>> /sbin/upstart and systemd in ubuntu14.10”.And  how is the reasion?
>
> Sorry, I cannot parse this.
>
> You use "initctl" as user for the user upstart, and you don't use it
> as root for system services when the system is running systemd.
>
> Martin
>
> --
> Martin Pitt| http://www.piware.de
> Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.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
>

-- 
Regards,

Dimitri.

-- 
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: systemd-fsck@.service

[Dimitri John Ledkov]

On 2 December 2015 at 13:14, Colin Watson  wrote:
> On Mon, Nov 30, 2015 at 05:29:35PM +0200, Tom H wrote:
>> 1) How does the unit now what "%f" is?
>
> See the "SPECIFIERS" section of the systemd.unit(5) manual page.
>
>> 2) "%i" is, in the case that I set up a few weeks ago,
>> "sys-devices-pci:00-:00:0d.0-ata4-host3-target3:0:0-3:0:0:0-block-sdb-sdb1".
>> Should it have "sdb" in it since it's supposed to be an unstable name?
>
> There doesn't seem any particular reason for the various %i.device units
> that this particular service is bound to to need stable names.  The
> purpose of systemd-fsck@.service is just to run fsck on all your block
> devices; it doesn't much matter what they're called.
>
> Jobs that need to run on only particular block devices would typically
> be udev rules rather than systemd units, I think; but if need be a
> systemd unit could always use udevadm to inspect the udev database for
> information about a particular device.  (There may be some better way.)
>

udev rules can add magic variables to trigger systemd units. Thus e.g.
leave a systemd unit inert and use udev rules to add systemd_wants=
variables et.al. see
http://www.freedesktop.org/software/systemd/man/systemd.device.html

-- 
Regards,

Dimitri.

-- 
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: Ubuntu : developing Android native apps!

[Dimitri John Ledkov]

Hello,

I do not provide end-user / end-developer support.

It is best to ask these questions elsewhere e.g. in ubuntu-devel-discuss
mailing list, where multiple people can answer your question, and both
questions and answers are archived and are discoverable with search engines.

Have you trying googling for solutions of your problem?

Maybe try ubuntu-make, it's a tool to support all kinds of development:
https://wiki.ubuntu.com/ubuntu-make

Regards,

Dimitri.


On 15 November 2015 at 15:24, Mayuresh Kathe  wrote:

> Hi,
>
> Since you are the original maintainer of the "android-emulator" under
> Ubuntu, thought it best to ask this off you.
>
> Is there any kind of ready to install (apt-get install ...) package
> collection under Ubuntu to allow native app development for Android?
>
> Also, is there any PPA I could add in to my list of repositories which is
> geared towards providing tools for Android development? preferably native
> app development!
>
> Thanks,
>
> ~Mayuresh
>
>


-- 
Regards,

Dimitri.
-- 
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: Wubi

[Dimitri John Ledkov]

On 25 August 2015 at 09:27, Alan Pope alan.p...@canonical.com wrote:
 Hi,

 On 21 August 2015 at 14:01, Dimitri John Ledkov x...@ubuntu.com wrote:
 On 21 August 2015 at 13:53, Alan Pope alan.p...@canonical.com wrote:
 On 21 August 2015 at 13:45, Michael Hall mhall...@ubuntu.com wrote:
 Modern Windows releases broke Wubi, so we stopped shipping and
 supporting it a while back. As far as I know it's a dead-end now.


 We didn't stop shipping it. I just downloaded the 15.04 desktop iso.


 but it's only used in greeter mode on windows which shows a GUI window
 and offers one to reboot.


 That doesn't work.

 I grabbed the latest supported release (amd64 desktop 15.04 iso) and
 put it on a USB stick, shoved that in a Windows 10 machine. The efi
 partition gets mounted by Windows, but it sees the rest of the stick
 (containing wubi.exe crucially) as un-partitioned space.


Interesting, we are supposed to have autorun.ini, which launches wubi
thing of CD/DVD when inserted...
Looks like windows is mounting the uefi partition, instead of the
Joliet which it claims non-recognised.


 So from my one-off test on a fairly standard Windows 10 install, wubi
 can't work.

 launching wubi.exe off the cd doesn't start wubi installer.


 I assume you mean usb stick (or perhaps DVD) where you say cd as
 the 15.04 image doesn't fit on a CD. I didn't test the DVD use case,
 but certainly can once I dig a blank DVD out.


I mean DVD. Something for a DVD drive looking around my house I
don't have a dvd drive on any of my machines any more.

 if one moves the wubi.exe off the disk however, it still shows the
 installer mode if one wants to brick their windows


 I don't believe we should be in the business of shipping known
 brick-making software.

 We should fix these issues or drop them. We have no resources to
 maintain this (as I understand it). I therefore recommend we remove
 wubi from the CD image completely. If someone in the community wants
 to take over the project, and serve up the (fixed) wubi.exe from
 somewhere for those users who need it, I think that's a better way
 forward than us having a broken version on our ISO.


That would be an action for foundations.

-- 
Regards,

Dimitri.

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

[Dimitri John Ledkov]

On 21 August 2015 at 13:53, Alan Pope alan.p...@canonical.com wrote:
 On 21 August 2015 at 13:45, Michael Hall mhall...@ubuntu.com wrote:
 Modern Windows releases broke Wubi, so we stopped shipping and
 supporting it a while back. As far as I know it's a dead-end now.


 We didn't stop shipping it. I just downloaded the 15.04 desktop iso.


but it's only used in greeter mode on windows which shows a GUI window
and offers one to reboot.

launching wubi.exe off the cd doesn't start wubi installer.

if one moves the wubi.exe off the disk however, it still shows the
installer mode if one wants to brick their windows

Regards,

Dimitri.


 alan@deep-thought:~/Downloads⟫ sudo mount -o loop
 ubuntu-15.04-desktop-amd64.iso ./iso
 [sudo] password for alan:
 mount: /dev/loop0 is write-protected, mounting read-only
 alan@deep-thought:~/Downloads⟫ ls -l iso/wubi.exe
 -r--r--r-- 1 root root 2573712 Oct 17  2014 iso/wubi.exe

 Cheers,
 --
 Alan Pope
 Community Manager

 Canonical - Product Strategy
 +44 (0) 7973 620 164
 alan.p...@canonical.com
 http://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

-- 
Regards,

Dimitri.

-- 
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: equivalent of chkconfig

[Dimitri John Ledkov]

On 4 August 2015 at 23:28, Luis Mondesi lem...@gmail.com wrote:
 Exactly for those reasons.

 What we probably would like to see is update-service which would wrap all 
 init services into one umbrella.

 update-service --list # shows all services and init running it: runit, 
 upstart, systemd, and sysv to start
 update-service command service [service] # for trying to call command 
 for each of the services' init systems. Essentially, same as /sbin/service 
 does in Fedora/RHEL 7 which was missed in Debian/Ubuntu. The difference is 
 that this tool would also work in batch mode and also enable/disable services.


service command is available in both debian and ubuntu, and integrated
throughout to work with sysv, upstart and systemd...

 --
 Luis

 On Aug 4, 2015, at 17:59, João M. S. Silva joao.m.santos.si...@gmail.com 
 wrote:

 Moreover:

 $ update-rc.d modemmanager enable
 update-rc.d: /etc/init.d/modemmanager: file does not exist


 On 08/04/2015 10:34 PM, Luis Mondesi wrote:
 I believe RHEL 7 does the right thing with chkconfig. It's simply an
 abstraction. Systemctl is fine, but that's probably overkill for simply
 turning things on or off.

 systemctl status foo
 systemctl disable foo
 systemctl stop foo

 As opposed to:
 chkconfig foo off

 My guess is that it should be relatively simple to write your own
 wrapper once you know what you're doing. However, to keep things simple
 for everybody else, it's better to have somebody who knows better
 actually write this wrapper for the rest of us. That way the
 documentation stays simple for all future init replacements. Makes the
 vendors happy as well as the end users.

 Just my 2 cents...

 --
 Luis

 On Aug 4, 2015, at 16:09, Martinx - ジェームズ
 thiagocmarti...@gmail.com mailto:thiagocmarti...@gmail.com wrote:

 Does chkconfig still works with systemd?


 On Tue, Aug 4, 2015, 16:59 João M. S. Silva
 joao.m.santos.si...@gmail.com mailto:joao.m.santos.si...@gmail.com
 wrote:

What do you mean?

Installing chkconfig in Ubuntu?

On 08/04/2015 08:51 PM, Bob Holtzman wrote:
 On Tue, Aug 04, 2015 at 05:38:03PM +0100, João M. S. Silva wrote:
 Hi,

 I suggest an equivalent of Fedora's chkconfig for server startup
 service administration.

 It seems strange that a simple solution for this problem does not
 already exist, but from all the questions that I've checked, that
 seems the case:



 http://askubuntu.com/questions/656496/how-to-enable-disable-startup-services-in-ubuntu



 http://askubuntu.com/questions/19320/how-to-enable-or-disable-services?lq=1

 etc.

 Something wrong with downloading/installing it from a repo?


--
João M. S. Silva

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

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

 --
 João M. S. Silva

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

-- 
Regards,

Dimitri.

-- 
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: DPDK for Ubuntu / Debian, let's do it?

[Dimitri John Ledkov]

Heya,

On 11 July 2015 at 05:06, Martinx - ジェームズ thiagocmarti...@gmail.com wrote:
 Hey guys,

  Any plans to package Intel DPDK for Ubuntu?

  Also, what about integrating Open vSwitch with DPDK (after package ready)?


I'd be interested in doing this in Debian (and thus in Ubuntu). My
networking knowledge is limited however, but this sounds like fun
though.

-- 
Regards,

Dimitri.

-- 
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: btrfs plans for 15.10/16.04?

[Dimitri John Ledkov]

On 21 Apr 2015 2:07 pm, Martinx - ジェームズ thiagocmarti...@gmail.com wrote:

 On 21 April 2015 at 16:36, Bryan Quigley bryan.quig...@canonical.com
wrote:

 Hi there,

 I'm just wondering if there are any plans to revisit btrfs as the
default filesystem before the next LTS?


So on Suse, btrfs is used for rootfs but not user storage (e.g. /home is on
xfs). I see that attractive, as /usr is mostly read-only and only updated
with controlled tools.

 Some key drivers I see are:
  - If we want our app/snappy story to converge with systemds [1]
  - LXC is even awesomer on btrfs (fast copies)

 AFAICT the last time this was condired was in the 12.10/13.04 timeframe
[2].

 Thanks!
 Bryan


 [1]
http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html
 [2]
https://blueprints.launchpad.net/ubuntu/+spec/foundations-r-btrfs-requirements


 Hey guys!

 Let me ask something here...

 Does Canonical / Ubuntu have plans to kick apt/dpkg in favor of some kind
of systemd install my-package?


That's not inline with systemd upstream. It only has support for offline
updates with reboot. (See needs update conditions etc.)

However see snappy / click and system image updates.

 About BTRFS, it still can not be used to host KVM QCow2 images, neither
/var/lib/mysql directories... Since it lacks support for DIRECT_IO.


Setting the flag to disable copy on write is available however.

 Cheers!
 Thiago

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

-- 
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: pidgin package update...

[Dimitri John Ledkov]

On 17 February 2015 at 22:32, Anonymous anonym...@hoi-polloi.org wrote:
 Hi there! There is a Pidgin update from pidgin.im with some security fixes in 
 October that are not currently in the Ubuntu Pidgin package.

 Ubuntu has us at Pidgin 2.10.9, and Pidgin 2.10.10 is out with some security 
 updates. I was hoping you folks could take a look at updating the package for 
 Ubuntu users.


Check the CVE rather than version numbers.

CVE tracker at http://people.canonical.com/~ubuntu-security/cve/

All of those CVE fixes are released in all supported ubuntu releases.
See package version numbers with fixes in pages below.

http://people.canonical.com/~ubuntu-security/cve/2014/CVE-2014-3694.html

http://people.canonical.com/~ubuntu-security/cve/2014/CVE-2014-3695.html

http://people.canonical.com/~ubuntu-security/cve/2014/CVE-2014-3696.html

http://people.canonical.com/~ubuntu-security/cve/2014/CVE-2014-3698.html

 Some refernce links:

 https://pidgin.im/news/security/

 https://www.pidgin.im/download/ubuntu/

 Thanks!

 -Joe Blow

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



-- 
Regards,

Dimitri.

-- 
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: Bug Triage Beginner question about package dependencies for file-roller

[Dimitri John Ledkov]

On 24 January 2015 at 08:04, Gunnar Hjalmarsson gunna...@ubuntu.com wrote:
 Hi Dave!

 On 2015-01-24 01:21, Dave Kokandy wrote:
 I am getting started with bug management in Lubuntu, and one bug seems
 like it would be fixed by making the package file-roller depend on
 yelp (currently recommended, but not required).

 That bug is 1409185: File Roller help is missing in Lubuntu
 https://bugs.launchpad.net/hundredpapercuts/+bug/1409185

 I thought that recommends were installed by default. Maybe I was wrong,
 or maybe Lubuntu is an exception in this respect.


seeds can choose whether to install recommends or not.
lubuntu is one flavour that chooses not to.

 Is that something that could be made a dependency? Or is that not
 possible because the help section is not core to the function of the app?


if you want that on CD discuss it with lubuntu leads to include it in
the lubuntu seed.
see launchpad.net/ubuntu-seeds


 It's technically possible indeed. The question is whether those who
 prepare Lubuntu have excluded yelp (and other recommends) deliberately
 for some reason.

 Or, if not, could another solution be to give a more clear error message
 explaining that the reason help cannot load is because yelp is missing?

 Another possible solution, indeed.

 Thank you for reading this email. If this is not the appropriate venue
 for this question, please let me know.

 Normally a bug report is sufficient to find out a solution. But your
 post here is no problem. Hey, it called my attention to the issue and
 gave me the opportunity to add another task to the bug report. ;)

 --
 Gunnar Hjalmarsson
 https://launchpad.net/~gunnarhj

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

-- 
Regards,

Dimitri.

-- 
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: Updater can't update kernel due to disk space

[Dimitri John Ledkov]

On 15 January 2015 at 21:04, Adam Conrad adcon...@ubuntu.com wrote:
 On Thu, Jan 15, 2015 at 10:49:42AM -0600, Dustin Kirkland wrote:
 On Thu, Jan 15, 2015 at 9:12 AM, Adam Conrad adcon...@ubuntu.com wrote:

  I can see several ways power users can shoot themselves in the foot
  with autoremove, but no way that normal people can, and I'm not sure
  catering to people who think they're clever doing unclever things is
  the right default.

 Autoremoving kernels, when you have lots of them, and as long as you
 keep your current one (and one other known good one), should be very
 safe, for almost any user.

 Right, kernel autoremoval is always safe.  Where people can shoot
 themselves in the foot (assuming automatic autoremove) is the following
 sort of scenario:

 1) Corporate IT dept distributes end-user bundle of apps by way of a
private repo consisting of all apps, and a company-meta package that
depends on them.

 2) The company-meta package isn't in the metapackages section (which
apt treats specially).

 3) User (with root, so already a small subset) removes company-meta

 4) On the next autoremove, all the company apps are removed.

 This scenario is a non-issue for the Ubuntu archive, we treat our meta
 packages correctly, and install things in a way that removing the meta
 should do no harm.

 Ultimately, I think optimising for the fear of autoremove causing harm
 is the wrong thing at this point, and we're better off doing the cruft
 removal.  This isn't just about kernels (though, they're the huge thing
 people notice), but also old libraries you no longer need, etc.

Can auto-remove accept a pattern of things to remove? E.g. apt
autoremove linux-*

Imho:

dist-upgrader should remove old kernels during clean-up stage (it does
a few cleanup tasks already)

update-manager should actually invoke autoremove linux-* when things
fail due to out-of-disk space on /boot, at the moment it pops up a
dialog with suggestion to run autoremove.

if automatic updates are enabled(apt upgrade, not full-upgrade) it
should be safe to run autoremove linux-* as well.
Or just give better instructions that one should enable autoremove as
well. (periodic apt supports it).

-- 
Regards,

Dimitri.

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

[Dimitri John Ledkov]

On 2 December 2014 at 10:11, Stephen P. Villano
stephen.p.vill...@gmail.com wrote:

 On 12/2/14 2:59 AM, Enrico Weigelt, metux IT consult wrote:
 On 02.12.2014 08:27, Martin Pitt wrote:
 Enrico Weigelt, metux IT consult [2014-12-02  7:55 +0100]:
 By the way: is it then be mandatory ?
 Yes, it will be. As Scott and others have already pointed out, Ubuntu
 never offered a choice of init systems, and doesn't plan on doing so.
 Okay, thanks for the clear statement.

 So we don't have to bother w/ Ubuntu anymore at all (besides migrating
 away), we can concentrate on Devuan. (eg. getting rid of polkit etc).
 The only blocker right now is Zimbra, which is currently not packaged
 for Debian yet - but as we'll move to OpenZimbra anyways once it's
 stable, we won't have any need for Ubuntu anymore.


 cu
 --
 Such is the nature of life in the world, especially in the world of
 software and operating systems.
 Personally, I prefer SElinux to polkit, but such isn't part of the

SElinux and SMACK are enabled in Ubuntu Kernels, and core packages are
compiled with SElinux features enabled thus one can use SElinux
policies on ubuntu base.
Ditto with smack. Thus in certain ways ubuntu is more flexible and
accommodating. Especially when it comes to cruitial hardware support 
technologies.

The rest of email is has just as bogus claims.

Regards,

Dimitri.


 baseline of Debian and hence, not part of Ubuntu. I just had to take
 other measures to ensure security.
 Ubuntu follows Debian rather faithfully in the baseline OS. That is the
 policy, it leaves a lot less to clean up after and gives a clear
 understanding of the lineage and sourceline of the OS itself. Ubuntu
 branches off in several areas, but they're well defined areas and well
 documented by the Ubuntu team.
 Personally, I use RedHat for certain uses in the enterprise network I
 operate in. I also use Fedora and CentOS in that same environment,
 depending upon the client environmental preferences.
 At home, my OS of choice is a bit more eclectic. I used to run SuSE
 until Novell screwed it up. Since, I've got a rather varied environment
 in both my lab environment at home and my production environment at
 home. I run a full enterprise network at home.
 For my home entertainment system, I use Mythbuntu, as it's clean running
 out of the box and harden my security with a clear comprehension of
 Ubuntu and Debian practices.
 Other systems are hardened according to US DoD standards or rather
 loose, depending upon which VLAN they live on and their purpose and
 sensitivity to the function of my home enterprise.
 As for my qualifications, I worked my way up from cable monkey to
 desktop support, help desk, LAN/WAN operations and senior level
 AD/SA/LAN/WAN operations before I moved into Information Assurance. In
 that latter field, I've not had a network I was responsible for be
 compromised and that counts being in the middle of the 2008 cyberattack
 against the US DoD in my area of responsibility. Every other network was
 compromised, mine was not. I don't take chances in security.

 So, stay with the distro or go your own way, it's a somewhat free world.
 Free as in beer is not free, but personal choices are free in most areas.

 Good night/morning, this discussion has so engaged me and emotionally
 aroused me, I'll now go to bed.
 Oh wait, it didn't.
 I outgrew If you're not going to play *my* way, I'm taking my marbles
 and go home when I left kindergarten, which was long enough ago that I
 do clearly recall watching John F. Kennedy shot live on television.
 But, I am serious about going to bed. Both out of lack of adrenaline and
 it's past bedtime by a few minutes.


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

-- 
Regards,

Dimitri.

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

[Dimitri John Ledkov]

Heya,

On 2 December 2014 at 11:57, Diego Germán Gonzalez
diegogermangonza...@gmail.com wrote:
 El 02/12/14 a las 08:12, Tom H escibió:

 Why would Ubuntu give its users a choice of init now when it hasn't in the
 past?

 --

 Why use Unity when we always use Gnome?
 Why use LibreOffice when we always use OpenOffice?
 Why use Mir when we always use Xorg and all the rest will use Wayland?
 Again, I have no opinion about it, but something has not been done so far is
 not argument that can not be done in the future


You missed the point of the question. Each flavour released by Ubuntu
Project serves a concrete purpose and has one good default only.
That is the one thing that is core to the Ubuntu Project and has been
the case always.

Each ubuntu flavour only ships one DE, one productivity suite, and one
graphical stack.

Some of this things and choices are different for each flavour.

However most flavours use the same kernel config. All ubuntu flavours
use the same glibc and toolchain. As those are things inherited from
Ubuntu Core which is common across all.
And at the moment the cores init system is upstart. There is plans and
work to migrate to systemd. Once that is done, and all flavours are
validated / ported as well, only one init will remain.
This is exactly the same way how Core has transitioned to new baseline
in the past in the Ubuntu project. And for each of those things Ubuntu
project selects the best option for it, and doesn't ship multiples
(e.g. we never supported eglibc  glibc at the same time, we did
change the default from one project to another over the past years as
the conditions changed).

-- 
Regards,

Dimitri.

-- 
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: The fate of Upstart

[Dimitri John Ledkov]

On 28 November 2014 at 12:41, Ben Tinner bentin...@yahoo.com.sg wrote:
 Hello


 Recently, the developers of Ubuntu have decided to migrate the init system
 from upstart to systemd.

 So, I would like to find out what will happen to upstart after Ubuntu
 complete its transition to systemd.

 Will development of upstart be abandoned after the transition is completed?

At the moment Ubuntu Phone, Ubuntu (and derivatives) and ChromeOS are
the largest users of Upstart.

Ubuntu 14.04 LTS is a long-term supported release, 5 years, until 2019.

Similarly, 16.04 LTS is not yet planned, thus i'm not sure whether it
will or won't ship upstart. If it does, it will be another 5 years
from then, or 2021.

I do not know the support time-frames of the phone product, it's a
question for Canonical and their partners, rather than the Ubuntu
project. But at the moment it is based on Upstart as well.

2019-2021 is far enough into the future that all predictions are moot.
Upstart is very large and stable piece of software and it is not under
active (rewrite) / feature work. Thus latest work is mostly focused on
extending and creating optional features or fixing corner case bugs in
the core.

One of the largest portions of work that is not merged is incomplete
support for FreeBSD kernel (and GNU user-space) as shipped by the
Debian kFreeBSD port. That has stalled a bit, since my interests have
shifted and Debian kFreeBSD port is no longer planned for
official-official release.

-- 
Regards,

Dimitri.

-- 
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: Thoughts about software-properties

[Dimitri John Ledkov]

Heya,

On 2 August 2010 14:04, Mohammed Amine IL Idrissi
ilidrissiam...@gmail.com wrote:
 Hi,
 I was discussing with Michael Vogt about an idea I've had for a long time,
 and he recommended me to share my thoughts here. So, here goes nothing:

 Software-properties is one of the few applications that still relies on
 gksu. I was about to convert it to aptdaemon/policykit, when I thought of
 this: Why don't we just separate software-properties into both
 update-manager and software-center?

There was also a proposal from mpt to make software-properties a panel
inside [gnome|unity-]control-center instead of a stand-alonish app.
My secret plan to achieve that was going to use gtk plug/socket to
embed software-properties written in python into otherwise compiled
.so control-center panel plugin.

This is the root pagadim behind mockups in
https://wiki.ubuntu.com/SoftwareUpdateHandling#settings. That way all
aps related to updates can launch/open control-center to control such
a core part of the operating system.

-- 
Regards,

Dimitri.

-- 
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: root and capabilities list

[Dimitri John Ledkov]

On 15 October 2014 02:11, ds 1000hz.radiow...@gmail.com wrote:

 On 15.10.2014 04:54, Colin Watson wrote:

   Martin's right - CAP_SYS_MODULE is functionally equivalent to root.

 I see.
 Anyway, there is another part, reading the msr and cpuid. For that, it seems
 to be really beneficial, to make it available to everyone. So the process
 which needs it, can only live with limited CAP_SYS_RAWIO powers. It seem to
 me, that the root rights are there only because the capability system was
 introduced only a couple of years ago, and the msr and cpuid part was not
 yet changed with capabilities in mind.
 As i said, i am new to linux, so not sure how it all works, and where to
 discuss the whole thing.

#include cpuid.h

And then use __get_cpuid() for cpuid. I believe it's possible to
retrieve it without being root that way.
As user-space libraries use that to check if they can/cannot execute
certain optimized instructions.
(e.g. checking for SSE)

-- 
Regards,

Dimitri.

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

[Dimitri John Ledkov]

On 17 May 2014 06:53, Charl Wentzel charl.went...@vodamail.co.za wrote:
 On 17/05/2014 01:35, Dimitri John Ledkov wrote:

 On 16 May 2014 07:26, Charl Wentzel charl.went...@vodamail.co.za wrote:

 I wanted do to debugging in Eclipse which required me to let Eclipse run
 gdb with sudo.  However, for this to work, sudo must not ask for a
 password.  So I've added the following entry in /etc/sudoers under the
 appropriate comment:

 If you simply want to grant unrestricted permissions for gdb to attach
 to any process, you don't need to grant full sudo to it.

 Thanks, I'll have a look into it.

 Are there any other reasons why you want to run gdb as root from eclipse?

 Yes, I'm writing an application that works with /dev/port for setting IO
 states.  I've looked into a few options, but none of the quite suited me:


Whilst coding you may want to open up /dev/port, e.g.
$ sudo chmod g+w /dev/port # if you need r/w access
$ sudo adduser `id -un` kmem
(re-login)

This will open up /dev/port for r+w to yourself (well anyone in kmem
group). This is slightly better than running things as root.

However, you'll need a solution to do something sensible in the
finally shipped application. E.g. do start your application as root
(or use setuid on the binary), execute ioperm()/iopl() to grant access
to I/O ports you need, and after that drop privileges. For more info
see http://www.tldp.org/HOWTO/IO-Port-Programming-2.html

This discussion is already out of scope for this mailing list however
=) as we are getting in the realm of just generic linux/unix
programming, more suited for something like stackoverflow / linux-unix
stackexchange and the like.

-- 
Regards,

Dimitri.

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

[Dimitri John Ledkov]

On 16 May 2014 07:26, Charl Wentzel charl.went...@vodamail.co.za wrote:
 Hi Guys

 I recently struggled with an issue for quite a few days because of the
 way the /etc/sudoers file is laid out.  I would like to make a
 suggestion to change it that would hopefully save others the same hassle.

 I wanted to debugging in Eclipse which required me to let Eclipse run
 gdb with sudo.  However, for this to work, sudo must not ask for a
 password.  So I've added the following entry in /etc/sudoers under the
 appropriate comment:

If you simply want to grant unrestricted permissions for gdb to attach
to any process, you don't need to grant full sudo to it.
By default, as a security measure, on ubuntu gdb is restricted from
tracing processes running by a different uid.
You can disable this security measure via normal sysctl measures, for
more details see:

http://askubuntu.com/questions/41629/after-upgrade-gdb-wont-attach-to-process

Are there any other reasons why you want to run gdb as root from eclipse?

Regards,

Dimitri.

-- 
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: Our Networking Story

[Dimitri John Ledkov]

On 6 March 2014 21:32, Benjamin Kerensa bkere...@ubuntu.com wrote:
 Why was it  necessary to have discussions internally when they could
 have been open by default?


Eh... this particular bug is public and well known in both Debian and
Ubuntu for a long time now.
As you can see in that email, he references a few things dating back
more than a year ago, but there is more one can dig through in
launchpad bug reports.

It's just it's making a new round of discussions about it, and he is
bringing this topic up at the upcomming UDS and is advertising the
session in advance =) to gather together relevant people.

Also, please do not top post, on ubuntu mailing list.

Regards,

Dimitri.

ps. Didn't you part Ubuntu Community?!


 On Thu, Mar 6, 2014 at 11:48 AM, Bryan Quigley
 bryan.quig...@canonical.com wrote:
 We've had a lot of internal Canonical discussions about our networking story
 and before going to a UDS session [1] it was suggested to post to
 ubuntu-devel.

 *Network Restart*
 I'd like to start by asking each of you what you think is the correct way to
 restart networking on Ubuntu server?  Feel free to write it down and include
 it in any replies :).

 It turns out our documentation has been wrong and the following are not
 correct and more importantly don't work consistently over 10.04/12.04/14.04
 [2]:
 sudo /etc/init.d/networking restart
 sudo restart networking

 The correct way I've been told is to use the ifupdown scripts. It's
 important to note that this is different on the desktop due to
 network-manager.

 I feel we need to publicly discuss if we really want the ifupdown scripts to
 be the only supported way to manage/restart networking.  We've been
 communicating the opposite for quite some time now..

 Related question:
 Do we not support giving users the ability to restart networking equivalent
 to rebooting the system?  (Upstart is used when booting, not when manually
 doing the ifupdown scripts).


 *More complicated network setups*
 There are many bugs in regards to bonds/vlans/bridging and other more
 complex networking setups.  It appears like it might be a limitation to how
 ifupdown is designed.

 We have had cases where the MTU needs to be set using a pre-up or post-up
 option in the interfaces file instead of a plain MTU line.
 Bond interfaces can cause significant pausing in boot/network restart
 The ifupdown script doesn't actually work on bonded interfaces [3]

 race condition updating statefile sometimes networking interfaces won't
 come up - was fixed [4]-

 We are seeing many more of cases involving complicated networking setups and
 with more OpenStack deployments this is going to become more of the norm.

 My understanding is that ifupdown was not designed to handle a parallel boot
 process like Upstart or systemd.  I'm guessing there are a lot more bugs
 lurking due to that, aside from some other issues with the codebase [5].

 *Future Releases*
 NetworkManager everywhere?  systemd-networkd?

 Thanks for discussing,
 Bryan


 [1]
 https://blueprints.launchpad.net/ubuntu/+spec/servercloud-1403-networking
 [2] If you want to see where those actually work see my document here:
 https://docs.google.com/document/d/1OBN3efJ1LmA0-0DzD3K0eUkIuQdscxLQ-QO1yi3bHeM/edit
 [3] https://bugs.launchpad.net/ubuntu/+source/ifenslave-2.6/+bug/1254120
 [4] https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1160490
 [5]
 http://pureperl.blogspot.com/2013/01/the-debian-ifupdown-package-and.html

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




 --
 Benjamin Kerensa
 http://benjaminkerensa.com
 I am what I am because of who we all are - Ubuntu

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

-- 
Regards,

Dimitri.

-- 
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: Full disk encryption for multiple disks

[Dimitri John Ledkov]

On 2 February 2014 14:47, Haug Bürger pi...@dokom.net wrote:
 Hi,

 I just tried to set up a secure system with multiple disks and found the
 Ubuntu installer more or less useless. It works for a single disk
 solution only. If you have a SSD and a harddisk and want all it all
 encrypted, you are lost.


Which installer did you use? Ubiquity as on desktop media, or d-i as
on server media?

d-i allows you to assemble multiple disks (using lvm, mdadm, dmraid,
etc.) and encrypt them as a singled encrypted block-device with a
single keystore.


 The current solution supports one password for one disk, only. This is a
 one-to-one relation between disk and password. This is nice if you have
 only one disk. For a multi disk setup the user has to insert a password
 for each disk, after fiddling with config files.


Please note that passphare used to decrypt an encrypted LUKS volume,
decrypts the disk-encryption key. And there can be up to 8 key-slots
in LUKS (8 different passphrases that decrypt the key with which one
can read the contents of the volume).

 As a user I want to set up a system encrypted with a password.  I don't
 want to key in the password N times each time I boot. It seems so easy
 to mount all disks with the same password, but it is not supported. As a
 user I want to key in one password for my system, independent of the
 number of disks it has.


By default, at the moment we do not cache entered passphrase for one
volume  try it with all others. Note that the actual encryption key
is different on each LUKS volume, it's just happens that the
passphrase in the key-slot is the same. I.E. if you re-initialise any
LUKS volume with old options and old passphrase you will loose all
data, as a new encryption will be used.

The usecase of one passphrase across multiple hard-disks is strange,
and is akeen of master passphrase. Typically one should use
different passphrases for each LUKS volume. If you have multiple
disks, which are utilised as a single system, it's best to e.g. use
RAID or LVM (as appropriate e.g. RAID0 level, non-replicated VG/LV )
first to create a single block devices our of multiple physcial
hard-drives, and then encrypt that as a single LUKS encrypted volume
with one passphrase. This way, user is only asked for decryption
passphrase once for the single encrypted volume that there is in that
system.


 If I have the requirement to dynamically mount disks, it is already
 possible. Just click on the drive and key in your password.

 The installer has to use one password for the system, not for the drive.
 It has to encrypt all disks set up during installation with the same
 password.


d-i allows you to arrange that, but note that it's not a maximally
secure solution for other use-cases that require more control over who
gets to decrypt what.
Once we go into security, we care to provide the maximally secure
solution for the most paranoid use-case first, and then optimise the
UX for the most common case. E.g. full-disk encryption for a
single-drive work station is one tickbox away in the installer.


 I wish these feature to be in the next Ubuntu release.


At the moment we use plymouth as boot time multiplexers for input and
output, and thus in default configuration debian/askpass.c utility is
not used (which has support for tokens / password caching at boot
time). When attempting to add support for calling into plymouth from
askpass, I have hit with a blocker - call to plymouth ask-for-password
is synchronous, and if askpass receives a password via another method
(e.g. via hardware token / dropbear ssh / etc) it was not possible to
cancel the ask-for-password request on plymouthd: remove the password
prompt, and unblock requests showing text messages to the user
crypt_foo unlocked via ssh and the rest of boot. Maybe I've
overlooked something, but a similar API help request on plymouth
mailing list from me was so far unanswered [1]. I haven't tried hacks
of providing dummy input to plymouth to unblock password entry state.

Finding the solution to unblocking/requests in plymouthd is the next
step to improve this functionality in the next Ubuntu release.

[1] http://lists.freedesktop.org/archives/plymouth/2013-March/000712.html

-- 
Regards,

Dimitri.

-- 
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: NetworkManager cleartext config files vs home folder encryption

[Dimitri John Ledkov]

On 25 December 2013 02:07, Per Guth mailingl...@perguth.de wrote:
 Hello,

 I recently stumbled over the fact, that NetworkManager by default stores
 Wifi profiles *including clear text passwords* under
 `/etc/NetworkManager/system-connections/`.


It's stored there because All users may connect to this network
ticked on that Wifi connection point. Open network indicator - Edit
connections ... - Select network - Click edit... - in general tab
untick All users may connect to this network.

If you do have multiple users, you may either setup wifi connection on
each user account or use Full-disk-encryption (requires repartitioning
or reinstallation).

 I think that is not what one expects when he/she turns on home folder
 encryption and should because of that be corrected somehow.[1]

 All the best,
 Per Guth

 [1]: I fixed it for me (a single user system) by moving the config files
 into my home folder as documented here:
 http://echt.guth.so/moving-networkmanager-config-files-to-home/


That guide worries me. One shouldn't need to compile a seuid binary =/
and especially not to interact with upstart, one can use policykit to
allow unprivileged users to control a system job.

If the GUI method to configure this, provided above, doesn't work, let me know.

Regards,

Dimitri.

-- 
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: NetworkManager cleartext config files vs home folder encryption

[Dimitri John Ledkov]

On 25 December 2013 10:31, Per Guth m...@perguth.de wrote:
 On 25.12.2013 10:36, Dimitri John Ledkov wrote:

 It's stored there because All users may connect to this network
 ticked on that Wifi connection point. Open network indicator - Edit
 connections ... - Select network - Click edit... - in general tab
 untick All users may connect to this network.

 I read about that. Unchecking that option moves the password into the user's
 keychain, which is neat.

 But it still leaves the question open: Does the regular Ubuntu user really
 expect that there will be clear text passwords for his Wifi networks outside
 his encrypted home folder (without taking additional steps)?


I don't remember, but i thought it was not the default. The
expectations are clear that things _outside_ of home directory are not
encrypted. One should use full disk encryption if full disk encryption
is expected ;-)

I don't worry about the WPA2 / typical WiFi passwords stored
unencrypted because they are not world readable, only root can read
them.

Routers are still shipped by ISPs and manufacturers with WPS enabled
by default, which is trivial to bypass in ~40 minutes using laptop /
smartphone. A few WPA setups are similarly easy to crack with traffic
analysis (aircrack etc). So the guide as it stands is a bit useless to
protect wifi password, if it can be cracked remotely anyway and one
didn't advise the user to turn those features off and use maximum
length WiFi passwords.

Creating setuid binaries as recommended in that guide is more harmful,
imho, as it opens up unprivileged root escalation.

And the guide doesn't protect the wifi passwords at all, as just like
before they are root readable or if one has physical access to the
machine. The only difference is, they are encrypted only whilst the
user is not logged in and machine is booted normally.

So my evaluation of the guide is that it does more harm then good, and
doesn't, at all, offer additional protection it claims to provide.

-- 
Regards,

Dimitri.

-- 
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: NetworkManager cleartext config files vs home folder encryption

[Dimitri John Ledkov]

On 25 December 2013 20:20, Martin Pitt martin.p...@ubuntu.com wrote:
 Dimitri John Ledkov [2013-12-25 14:15 +]:
 I don't remember, but i thought it was not the default.

 Until lucid or natty it indeed wasn't, it defaulted to per-user
 connections. But this is highly unfriendly with multiple users, you
 don't have network available in lightdm, and all our OEMs changed the
 default anyway, so since natty or precise or so NM now defaults to
 system-wide connections.

 (FWIW, I fully agree with this.)


yeah, makes sense. I only know about it, because I had to hunt it down
and fix multi-user systems =)
good that system-wide is the default now.

-- 
Regards,

Dimitri.

-- 
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: Including VirtualBox guest drivers in trusty iso.

[Dimitri John Ledkov]

Hello,

On 20 December 2013 10:04, Robie Basak robie.ba...@ubuntu.com wrote:
 On Fri, Dec 20, 2013 at 02:55:11PM +0530, staticd wrote:
 The drivers (virtualbox-guest-dkms, virtualbox-guest-x11,
 virtualbox-guest-utils) are in debian and ubuntu repos (universe) and total
 to only 1.8MB.

 What about dependencies? DKMS packages need quite a bit of supporting
 infrastucture (toolchain, kernel headers, etc) in order to function. Are
 these all already shipped on the CD, too?


Yes, we do. All default desktop/server installation have matching
kernel-headers  toolchain as needed to compile DKMS modules. Also if
third-party drivers is ticked in ubiquity, ubuntu-drivers fetches and
installs dkms-modules and/or binary drivers as needed, based on
declared Modaliases. Looks like virtualbox-guest-dkms package
doesn't declare any Modaliases, maybe it should be integrated with
ubuntu-drivers, if possible.

-- 
Regards,

Dimitri.

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