Lubuntu 24.04 LTS Participation/Recertification

[Thomas Ward]

All:

I wish to apologize for the tardiness of this note, but on behalf of the 
Lubuntu Council and the Lubuntu Team, I would like to reassert that Lubuntu 
will be participating in 24.04 LTS with a 3 year support period on our part.

Simon Quigley was present at today's TB meeting and made a note that he has a 
draft written up for the recertification paperwork and messages going to the 
TB, but I wanted to reassert that we're working on getting it fully filed, but 
I wanted to affirm we are still participating despite the delay in getting 
information to the TB and Release teams.

I wish to apologize on our slowness, lots of things happened towards EOY 2023 
and everyone got very busy, and this was delayed and overlooked, so my 
apologies to the Release Team and the Technical Board.



Thomas Ward
LP: ~teward
Lubuntu Team Lead
Secondary Lubuntu Release Manager
Lubuntu Council Member
-- 
Ubuntu-release mailing list
Ubuntu-release@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-release

Re: Responses Needed: Flavor Participation for 24.04 LTS

[Thomas Ward]

I can affirm with regards to Lubuntu that we are participating in 24.04 LTS, 
with a support period of 3 years as typical for Lubuntu.

We are working on getting everything necessary for the Technical Board 
recertification and will send that soon as well.


Thomas Ward
Lubuntu Team Lead
Lubuntu Council Member
LP: ~teward


From: ubuntu-flavors  on behalf of 
Simon Quigley 
Sent: Wednesday, November 8, 2023 2:04 PM
To: ubuntu-devel@lists.ubuntu.com ; 
ubuntu-flav...@lists.ubuntu.com 
Subject: Responses Needed: Flavor Participation for 24.04 LTS

Hello flavors!

As we do around the start of every new cycle, I am reaching out to all
the current official Ubuntu flavors to confirm active participation in
the upcoming Ubuntu release - 24.04 LTS, codenamed Noble.

Working towards a release requires a lot of effort, so we'd like to make sure
all the flavors are ready, properly staffed, and have enough time allocated to
make 24.04 LTS happen for their users. This is why, similarly to last time, I
will need a confirmation follow-up message about Noble participation and your
planned efforts this cycle from every flavor, that is:

  * Edubuntu
  * Kubuntu
  * Lubuntu
  * Ubuntu Budgie
  * Ubuntu Cinnamon
  * Ubuntu Kylin
  * Ubuntu MATE
  * Ubuntu Studio
  * Ubuntu Unity
  * Xubuntu

Diversity of opinion within the Ubuntu ecosystem makes us stronger. Flavors play
an important role in making a resilient, inclusive, and technically-sound
Ubuntu, for all of us, inspiring us to do better, and be better. As important
players within the project, we especially value your opinions, and are happy to
address concerns if you run into trouble.

This release, we are making a concerted effort to move off of Ubiquity entirely
and across the board, in time for the LTS. Ubuntu Budgie has paved the way for
flavor participation with the new Ubuntu Desktop Installer, while Lubuntu
continues to innovate and push the limits of what is possible with Calamares.
Whatever route your flavor chooses, it would be an incredibly wise decision to
move off of Ubiquity.

If you have any concerns regarding your participation, or a switch in
installers, please feel free to reach out to me, or anyone from the
~ubuntu-release team.

Thank you!

--
Simon Quigley
si...@tsimonq2.net
tsimonq2 on LiberaChat and OFTC
@tsimonq2:linuxdelta.com on Matrix
5C7A BEA2 0F86 3045 9CC8
C8B5 E27F 2CF8 458C 2FA4

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

RE: Updates to cacti for CVE-2023-39361 (CVSS 9.8)?

[Thomas Ward]

Nor is it likely a community member would be able to solve this.

I just went digging in Cacti, and even Debian was unable to get information 
about a pinpoint fix and patchset.

From https://github.com/Cacti/cacti/issues/5523 I am quoting their security / 
developers directly:

> Hi Paul,
> 
> The issue raised was listed as fixed in Cacti < 1.2.6. We did ask the 
> researcher for more information as we couldn't reproduce this under recent 
> Cacti versions, but we were only told that it was definitely resolved in the 
> latest code. I don't believe there is much on that issue that isn't already 
> released by him on his public posts about it.
> 
> We didn't do much with it, since it has already been fixed, and it seems to 
> only affect versions outside of what we currently support. If you need more 
> information on where to find his posts, I can send you them directly. Feel 
> free to reach out to me on the other channels.

Debian has updated their security vulnerability data as well on this CVE 
(https://salsa.debian.org/security-tracker-team/security-tracker/-/commit/3288ad78351071f170dd4da4d70a8a95065cb1ce):

> It is a very unfortunate situation that the fix is not pinpointed.
> Upstream believes 1.2.6 fixes the issue. Exceptionally update the status
> according to the current discussion.

There is no fix documented on the CVE or the GHSA documentation, nor any linked 
data available from that other than "This was fixed in 1.2.6 after discussion 
between Upstream and reporting researcher."

The Ubuntu Security Team may wish to reflect this information in the CVE entry. 
 Per Upstream, the reporter's blog post is referring to an at the time 
nonexistent 1.2.25 release.  It was indicated by TheWitness 
(https://github.com/Cacti/cacti/issues/5523#issuecomment-1768240843) on the 
Cacti GitHub repository that they meant this was fixed in 1.2.6 but not present 
in 1.2.25 which was released since then.


Thomas


-Original Message-
From: Ubuntu-devel-discuss  On 
Behalf Of Alex Murray
Sent: Monday, November 13, 2023 9:16 PM
To: chue...@pentics.com; ubuntu-devel-discuss@lists.ubuntu.com
Subject: Re: Updates to cacti for CVE-2023-39361 (CVSS 9.8)?

Hi chuegen,

As cacti is in the universe component of the repository, it is community 
maintained and therefore there is no timeframe as to when such a package will 
be patched in Ubuntu nor any clear indication if a community member is working 
on this at this time.

You can see the status of this CVE in the Ubuntu CVE Tracker at
https://ubuntu.com/security/CVE-2023-39361

Thanks,
Alex

On Tue, 2023-09-12 at 11:36:47 -0500, chue...@pentics.com wrote:

> Hi there,
>
> The Cacti project provided an announcement of a CVSS 9.8 SQL injection 
> bug against Cacti (fixed in 1.2.25).  Is this being worked, and how 
> long should I expect before a package becomes available in the Ubuntu 
> 22.04 security stream?  For now, I have disabled the functionality in 
> question while I await a package update (and I'd like to avoid having 
> to go with a local version of the updated package if it will be relatively 
> soon).
>
> -c
> --
> 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
-- 
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: allowing backports into non-LTS releases

[Thomas Ward]

Same with Mantic.

On 10/30/23 15:09, Thomas Ward wrote:
The only thing in Lunar's backports are the `cockpit` package, I 
forget did we give that an exception?



Thomas


On 10/30/23 10:58, Thomas Ward wrote:
I'll take a look at Lunar (didn't that just release though...?) as I 
have a server related task for that to work on.



Thomas


-Original Message-
From: ubuntu-backports  On 
Behalf Of Dan Streetman

Sent: Monday, October 30, 2023 10:55 AM
To: Backports Discussion 
Subject: allowing backports into non-LTS releases

I'd like to propose changing our rules to allow - but not require - 
backports into non-LTS releases. I think it makes sense to allow 
this, so the benefit of backports can be provided in non-LTS releases 
as well.


As we currently do have backports in the non-LTS lunar and mantic 
queues, and we've rescheduled our next meeting until the end of next 
month, if you have time @teward and @mapreri I'd like to discuss over 
the ML, so we can accept (or reject) the non-LTS uploads.


Thanks!

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


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

Re: allowing backports into non-LTS releases

[Thomas Ward]

The only thing in Lunar's backports are the `cockpit` package, I forget 
did we give that an exception?



Thomas


On 10/30/23 10:58, Thomas Ward wrote:

I'll take a look at Lunar (didn't that just release though...?) as I have a 
server related task for that to work on.


Thomas


-Original Message-
From: ubuntu-backports  On Behalf Of 
Dan Streetman
Sent: Monday, October 30, 2023 10:55 AM
To: Backports Discussion 
Subject: allowing backports into non-LTS releases

I'd like to propose changing our rules to allow - but not require - backports 
into non-LTS releases. I think it makes sense to allow this, so the benefit of 
backports can be provided in non-LTS releases as well.

As we currently do have backports in the non-LTS lunar and mantic queues, and 
we've rescheduled our next meeting until the end of next month, if you have 
time @teward and @mapreri I'd like to discuss over the ML, so we can accept (or 
reject) the non-LTS uploads.

Thanks!

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


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

RE: allowing backports into non-LTS releases

[Thomas Ward]

I'll take a look at Lunar (didn't that just release though...?) as I have a 
server related task for that to work on.


Thomas


-Original Message-
From: ubuntu-backports  On Behalf Of 
Dan Streetman
Sent: Monday, October 30, 2023 10:55 AM
To: Backports Discussion 
Subject: allowing backports into non-LTS releases

I'd like to propose changing our rules to allow - but not require - backports 
into non-LTS releases. I think it makes sense to allow this, so the benefit of 
backports can be provided in non-LTS releases as well.

As we currently do have backports in the non-LTS lunar and mantic queues, and 
we've rescheduled our next meeting until the end of next month, if you have 
time @teward and @mapreri I'd like to discuss over the ML, so we can accept (or 
reject) the non-LTS uploads.

Thanks!

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

RE: today's meeting

[Thomas Ward]

Sounds good, I'll be there!

-Original Message-
From: ubuntu-backports  On Behalf Of 
Dan Streetman
Sent: Monday, October 30, 2023 10:41 AM
To: Backports Discussion 
Subject: Re: today's meeting

I scheduled the next meeting for Nov 29, at the same (DST-aware) time, which 
results in 16:00 UTC (due to the DST change).

On Wed, Oct 25, 2023 at 9:35 AM Thomas Ward  wrote:
>
> agreee +1 on skipping
>
>
>
> Sent from my Galaxy
>
>
>
>  Original message 
> From: Mattia Rizzolo 
> Date: 10/25/23 09:15 (GMT-05:00)
> To: ubuntu-backports@lists.ubuntu.com
> Subject: today's meeting
>
> Today we are scheduled to have a meeting in less than 2 hours from now.
>
> I don't have any update concerning the current items nor my own TODOs 
> (sorry about this!), and I don't think we have any pressing issue/case 
> we need to discuss.
> I think it would be fine to just skip this meeting and jump on the 
> next one.
>
> --
> regards,
> Mattia Rizzolo
>
> GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
> More about me:  https://mapreri.org : :'  :
> Launchpad user: https://launchpad.net/~mapreri  `. `'`
> Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-
> --
> ubuntu-backports mailing list
> ubuntu-backports@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports

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

RE: today's meeting

[Thomas Ward]

agreee +1 on skipping



Sent from my Galaxy



 Original message 
From: Mattia Rizzolo 
Date: 10/25/23 09:15 (GMT-05:00)
To: ubuntu-backports@lists.ubuntu.com
Subject: today's meeting

Today we are scheduled to have a meeting in less than 2 hours from now.

I don't have any update concerning the current items nor my own TODOs
(sorry about this!), and I don't think we have any pressing issue/case
we need to discuss.
I think it would be fine to just skip this meeting and jump on the next
one.

--
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-
-- 
ubuntu-backports mailing list
ubuntu-backports@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports

Re: Merge ubuntu-motu@lists into ubuntu-devel-discuss@lists?

[Thomas Ward]

If the lists merge, I'm sure Canonical / Ubuntu IS can set up a redirect 
so that ubuntu-motu@lists.u.c redirects to 
ubuntu-devel-discuss@lists.u.c.  Email redirection is fairly trivial 
when you have access to control mail flow.  So I would not be as 
concerned about there being a "lost contact field" in that case.



Thomas


On 10/18/23 15:57, Laurent Lyaudet wrote:

Hello :),

I found this list while searching contact information for this package:
https://packages.ubuntu.com/lunar/python3-uinput
Search Ubuntu MOTU Developers on the web page.
I think there must be a good number of packages where this list is
given as contact.

Best regards,
 Laurent Lyaudet

Le mer. 18 oct. 2023 à 02:45, Steve Langasek
 a écrit :

Hi folks,

There is a mailing list, ubuntu-motu@lists.ubuntu.com, that sees very little
activity.  While MOTU as a concept still exists for those who are approved
uploaders to universe but not main (https://launchpad.net/~motu), it's been
quite some time that this list is not being used for discussions within that
subcommunity of developers.

Indeed, I think most MOTU are probably not tracking the list at all, and a
look at the message history over the past 6 months shows the only threads
started on there are from users asking for help with one universe package or
another.  It's not clear to me how users are finding this as a contact
address, but it's not a good experience for them; the list is infrequently
moderated (I have the impression that it's less frequently than
ubuntu-devel*), and there are only a handful of developers who answer on the
list (myself, Robie, maybe a few others?).

I'd therefore like to propose we close this mailing list and forward the
address on to ubuntu-devel-disc...@lists.ubuntu.com, which at least has a
larger subscriber base and is more likely to result in users getting help
with their questions.

Opinions?

--
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu


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

Re: Merge ubuntu-motu@lists into ubuntu-devel-discuss@lists?

[Thomas Ward]

If the lists merge, I'm sure Canonical / Ubuntu IS can set up a redirect 
so that ubuntu-motu@lists.u.c redirects to 
ubuntu-devel-discuss@lists.u.c.  Email redirection is fairly trivial 
when you have access to control mail flow.  So I would not be as 
concerned about there being a "lost contact field" in that case.



Thomas


On 10/18/23 15:57, Laurent Lyaudet wrote:

Hello :),

I found this list while searching contact information for this package:
https://packages.ubuntu.com/lunar/python3-uinput
Search Ubuntu MOTU Developers on the web page.
I think there must be a good number of packages where this list is
given as contact.

Best regards,
 Laurent Lyaudet

Le mer. 18 oct. 2023 à 02:45, Steve Langasek
 a écrit :

Hi folks,

There is a mailing list, ubuntu-m...@lists.ubuntu.com, that sees very little
activity.  While MOTU as a concept still exists for those who are approved
uploaders to universe but not main (https://launchpad.net/~motu), it's been
quite some time that this list is not being used for discussions within that
subcommunity of developers.

Indeed, I think most MOTU are probably not tracking the list at all, and a
look at the message history over the past 6 months shows the only threads
started on there are from users asking for help with one universe package or
another.  It's not clear to me how users are finding this as a contact
address, but it's not a good experience for them; the list is infrequently
moderated (I have the impression that it's less frequently than
ubuntu-devel*), and there are only a handful of developers who answer on the
list (myself, Robie, maybe a few others?).

I'd therefore like to propose we close this mailing list and forward the
address on to ubuntu-devel-disc...@lists.ubuntu.com, which at least has a
larger subscriber base and is more likely to result in users getting help
with their questions.

Opinions?

--
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
--
Ubuntu-motu mailing list
ubuntu-m...@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu


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

[Bug 2033645] Re: [BPO] libreoffice 7.5.6 for jammy

[Thomas Ward]

This has been accepted and is now in the queue pending publication.

** Changed in: libreoffice (Ubuntu Jammy)
   Status: In Progress => Fix Committed

-- 
You received this bug notification because you are a member of Ubuntu
Backporters, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/2033645

Title:
  [BPO] libreoffice 7.5.6 for jammy

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/2033645/+subscriptions


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

[Bug 2030259] Re: [BPO] Backport mozc from lunar to jammy

[Thomas Ward]

I give this a provisional ACK but want to check with mapreri or ddstreet
first for a second ack before handling.

-- 
You received this bug notification because you are a member of Ubuntu
Backporters, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/2030259

Title:
  [BPO] Backport mozc from lunar to jammy

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mozc/+bug/2030259/+subscriptions


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

augmenter la taille d'un disque dans VirtualBox

[Thomas De Contes]

bonjour :-)


comment augmenter la taille d'un disque virtuel dans VirtualBox ?


dans l'utilitaire "disques" je vois bien la nouvelle taille, mais pas 
dans "fichiers", et donc elle n'est pas rendue disponible pour qu'on 
puisse s'en servir.



--
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/


--
Liste de diffusion ubuntu-fr ubuntu-fr@lists.ubuntu.com
Pour s'abonner ou se désabonner : 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-fr
Charte de la liste: http://doc.ubuntu-fr.org/groupes/ubuntu-fr-ml/charte

Re: clés ssh multiples

[Thomas De Contes]

Le 22/08/2023 à 16:13, Dhenain Yves a écrit :

Bonjour

Le 22/08/2023 à 16:00, Thomas De Contes a écrit :

j'ai ajouté des clés avec IdentityFile.


quand ssh a besoin de ces clés, il affiche :

Enter passphrase for key '...':

C'est par ce que la clef à été générée avec une passphrase je suppose

oui


dans le terminal, au lieu de faire une invite dans l'interface 
graphique.


mais la clé principale aussi, et ca a bien été géré par l’interface 
graphique.





Du coup, ça n'est pris en charge par aucun mécanisme de gestion de 
mdp ! :-(



pourquoi ?

Est-ce qu'on peut arranger ça ?



--
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/


--
Liste de diffusion ubuntu-fr ubuntu-fr@lists.ubuntu.com
Pour s'abonner ou se désabonner : 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-fr
Charte de la liste: http://doc.ubuntu-fr.org/groupes/ubuntu-fr-ml/charte

remarques et demandes d’amélioration pour des logiciels spécifiques

[Thomas De Contes]

bonjour :-)


comment trouver à quel endroit on doit faire les remarques et demandes 
d’amélioration pour des logiciels spécifiques, pour gedit par exemple ?



--
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/


--
Liste de diffusion ubuntu-fr ubuntu-fr@lists.ubuntu.com
Pour s'abonner ou se désabonner : 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-fr
Charte de la liste: http://doc.ubuntu-fr.org/groupes/ubuntu-fr-ml/charte

clés ssh multiples

[Thomas De Contes]

bonjour :-)


j'ai ajouté des clés avec IdentityFile.


quand ssh a besoin de ces clés, il affiche :

Enter passphrase for key '...':

dans le terminal, au lieu de faire une invite dans l'interface graphique.

Du coup, ça n'est pris en charge par aucun mécanisme de gestion de mdp ! :-(


pourquoi ?

Est-ce qu'on peut arranger ça ?


--
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/


--
Liste de diffusion ubuntu-fr ubuntu-fr@lists.ubuntu.com
Pour s'abonner ou se désabonner : 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-fr
Charte de la liste: http://doc.ubuntu-fr.org/groupes/ubuntu-fr-ml/charte

[Bug 2030675] Re: [BPO] plastimatch/1.9.4+dfsg.1-2 for jammy (22.04LTS)

[Thomas Ward]

Changing the package to include two *external* sources is not proper,
because you will have packaging conflicts.

If this bug is relevant to other packages, then cherrypicking the patch
from upstream and following the Stable Release Updates process for
fixing/updating libinsighttoolkit5 is where you're going to need to
follow.  https://wiki.ubuntu.com/StableReleaseUpdates

However, that's independent from the Backports process and needs to be
handled that way.

It is not proper to 'bug fix' by doing Backports, that's what the SRU
process is for.

-- 
You received this bug notification because you are a member of Ubuntu
Backporters, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/2030675

Title:
  [BPO] plastimatch/1.9.4+dfsg.1-2 for jammy (22.04LTS)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/plastimatch/+bug/2030675/+subscriptions


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

[Bug 2030675] Re: [BPO] plastimatch/1.9.4+dfsg.1-2 for jammy (22.04LTS)

[Thomas Ward]

As a backporter *and* a Developer, I have some major concerns about this
request.

(1) This has no developer backing.  One of the major things about a
Backport is it needs a developer or sponsor willing to push this
through.  I don't see any tied to this request.

(2) This request does **not** have any prepared packaging.  Part of the
requirements for backports is that packaging is prepared that *functions
as expected* for upload to the target release.  There isn't, which
should imply that the package works as is, however,

(3) The package requested fails to build from source and is NOT able to
be built on requested target OS.  There is no 'fixed' packaging or
debdiff available to 'fix' this problem here.

The Backports team is **NOT** responsible for making sure the packages
requested build properly on the target OS.  It is up to the requestor
and the developer/sponsor who is helping with this process to handle.

You note in your request that the package "would need modification".
Until a functional package diff is provided by either you or a
developer, this backport request does NOT meet the requirements for
backports.  The Backports team is not responsible for modifying the
package to function, that's a requirement for the requestor - refer to
https://wiki.ubuntu.com/UbuntuBackports#Responsibilities_of_the_Backporter
for what responsibilities you have as the requestor of a backport.

I am marking this as "Incomplete" against Jammy until the requirements
are met so the request is suitable for the Backporters team to review.

** Changed in: plastimatch (Ubuntu Jammy)
   Status: New => Incomplete

-- 
You received this bug notification because you are a member of Ubuntu
Backporters, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/2030675

Title:
  [BPO] plastimatch/1.9.4+dfsg.1-2 for jammy (22.04LTS)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/plastimatch/+bug/2030675/+subscriptions


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

[Bug 2030675] Re: [BPO] plastimatch/1.9.4+dfsg.1-2 for jammy (22.04LTS)

[Thomas Ward]

@GregSharp

It's invalid against the Development release, Mantic.  We added the
series target for Jammy which is what you requested the target OS to be.
"Invalid" for a bare package bug is against the devel release, not for
the entire request, because we track that by series tasks/targets.

-- 
You received this bug notification because you are a member of Ubuntu
Backporters, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/2030675

Title:
  [BPO] plastimatch/1.9.4+dfsg.1-2 for jammy (22.04LTS)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/plastimatch/+bug/2030675/+subscriptions


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

[Bug 2030675] Re: [BPO] plastimatch/1.9.4+dfsg.1-2 for jammy (22.04LTS)

[Thomas Ward]

** Also affects: plastimatch (Ubuntu Jammy)
   Importance: Undecided
   Status: New

** Changed in: plastimatch (Ubuntu)
   Status: New => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Backporters, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/2030675

Title:
  [BPO] plastimatch/1.9.4+dfsg.1-2 for jammy (22.04LTS)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/plastimatch/+bug/2030675/+subscriptions


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

Re: Test RAM

[Thomas De Contes]

Le 23 mars 2023 à 06:29, Pierre Guiard a écrit :

> Beaucoup de cartes mère sérieuses( HP, Dell, Asus) embarquent un contrôleur 
> de Ram qui fait aussi bien son boulot que Memtest.*

Il se trouve que c'est un HP avec lequel j'ai un problème.
Peux tu me préciser comment on procède stp ?


2 questions annexes :

- Combien de temps environ faut-il compter pour 4 Go de RAM ?

- Y a-t-il le même genre d'avantage sur les NUC ?


-- 
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/


-- 
Liste de diffusion ubuntu-fr ubuntu-fr@lists.ubuntu.com
Pour s'abonner ou se désabonner : 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-fr
Charte de la liste: http://doc.ubuntu-fr.org/groupes/ubuntu-fr-ml/charte

RE: self-approval of uploads to -backports pocket

[Thomas Ward]

I'll make some inquiries on my end, I already hinted to ogra that if we can't 
reach Martin then we are going to have to escalate this - maybe to the TB for 
"abuse of technical privileges", maybe higher (Mark?).



Sent from my Galaxy



 Original message 
From: Dan Streetman 
Date: 5/23/23 09:14 (GMT-05:00)
To: martin.p...@ubuntu.com
Cc: Backports Discussion 
Subject: Re: self-approval of uploads to -backports pocket

Unfortunately it seems this message didn't get to Martin, as today
there was another self-approved upload for cockpit.

I'm not sure what to do about this? Does anyone know of a
better/different email to reach Martin at? Should we reach out to
archive admins to ask what to do? Should we just ignore it and let him
continue to self-approve his backport uploads?

On Sun, Mar 26, 2023 at 1:53 PM Dan Streetman  wrote:
>
> Hi Martin,
>
> It seems you have been uploading the cockpit package to the backports
> pocket for some releases, and then approving the upload yourself.
>
> While you (clearly) still have technical access to approve uploads to
> the backports pockets, the process has changed and you are no longer
> on the backports team, and thus you should not be approving any
> uploads to the backports pocket.
>
> While we're happy to review any uploads you make to the backports
> pocket, please don't approve any more uploads to backports; let your
> uploads proceed through the normal process.
>
> Thanks.

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

Re: Special One-Time SRU Handling request for torbrowser-launcher

[Thomas Ward]

Robie,

To cherry pick this would require extensive reverse engineering of the 
code to figure out which pieces apply to the *older* versions of 
torbrowser-launcher.  Unfortunately, since there are no *bugfix* 
releases of torbrowser-launcher upstream and everything is interspersed 
among larger-scale feature changes, this prevents us from easily 
cherrypicking the code.  Essentially, to reverse engineer this patch 
would take much MUCH more time and effort to make functional.


However, we have a second consideration point.  With torbrowser-launcher 
0.3.6, we have a major *upstream* change from Tor Browser itself (which 
is downloaded by torbrowser-launcher and installs it in userspace as Tor 
Browser prefers to live in) which involves the loss of all localization 
packages and one unified package for Tor Browser.  To nitpick *those* 
fixes is equivalent to a large feature change that is well-ingrained in 
the 0.3.5 -> 0.3.6 codebase change, and reverse engineering that from 
what I've attempted to do initially for Tor Browser is a nightmare.


Which leaves us with, really, two choices:

 1. Backport 0.3.6-2 in -updates to the older releases

 2. Won't Fix 277 and other bugs which will make the package 
unusuable (effectively: Critical bugging the older version which a lot 
of people use, because it's "no longer supported").


This is tantamount to Bitcoin from the history where Bitcoin would make 
hard forks or major non-reverse-compatible changes that can't be 
backported and in turn would require the newer version to be backported 
in order for `bitcoin` to even function.  The only difference between 
Bitcoin and torbrowser-launcher (and Tor Browser) is that this is the 
first major *historically breaking* change in upstream Tor Browser that 
prohibits simply 'backporting' these changes.


The two-line fix for launch window is minor, and we could theoretically 
survive that.  However, the URL fix is nontrivial to backport within the 
code, hence the request for a one-time special SRU to backport 0.3.6 to 
all current releases (except 18.04 because that's approaching it's EoSS 
date) in order to make everything function in the currently supported 
releases.



Thomas


On 4/6/23 15:55, Robie Basak wrote:

Hi Thomas,

Thank you for caring for this package in Ubuntu!

I'm not sure I follow why this is difficult to fix by cherry-picking
fixes. It seems to me that there are two bugs mentioned - one which is a
two line fix, and one which refers to upstream URLs changing, which
presumably is a change in a constant somewhere or similar.

Will cherry-picking or rewriting these trivial fixes not be enough to
fix the reported bugs? If not, why not?

Robie

On Sun, Mar 19, 2023 at 07:55:48PM -0400, Thomas Ward wrote:

I'm following up on this today, because Debian finally got off their lazy
butt and uploaded 0.3.6-2 to Debian that addresses the core problems in
Debian.

However, that does not solve the problems for everything in Ubuntu.  With
the blessing of the Release team, I did a sync last night (forced) of
0.3.6-2 from Debian Unstable to Ubuntu Lunar, which addresses
https://bugs.launchpad.net/ubuntu/+source/torbrowser-launcher/+bug/277
in Lunar.

Unfortunately the fix that is applied for this in 0.3.6-2 is interwoven with
all the changes from 0.3.3 to 0.3.6 upstream which includes new features.

I have not heard back from the Release team on this, or the SRU team, so I'm
re-asking this.  Is the SRU / Release team willing to let us do a one-time
backport from Lunar of 0.3.6-2 to the older releases currently supported (to
Bionic but no further backwards)?


Thomas


On 2/1/23 14:26, Thomas Ward wrote:

Hello, release team.


Pursuant to a recent change for torbrowser-launcher and Tor Browser, we
have a little bit of a conundrum that is leading to a one time request for
SRUing the latest `torbrowser-launcher` to all currently supported
releases.

With Tor Browser 12 (TB12 for short here), upstream tor browser no longer
uses locales, requiring folder cleanup from TB12 and download URL changes
in order for things to properly function.  Unfortunately, the code changes
necessary to implement the changes to torbrowser-launcher are not easily
nitpicked and include more than just these fixes, as it has new changes
and such to make it work properly. Refer to
https://bugs.launchpad.net/ubuntu/+source/torbrowser-launcher/+bug/277
as the current bug on this.

Debian is behind on updating upstream, so later today I will be preparing
a package for Lunar that will have a -0ubuntu1 prefix for the latest
upstream version.  That works fine in Lunar.  It also works fine in
Kinetic and in initial tests in Jammy.  I’m installing test environments
for Focal and Bionic.

The problem here is, though, we have a mix of “new features” and “bug
fixes” together – there is no ‘major version bump’ for feature branches
vs. ‘bugfix’ branches, making it a comingled problem of “new features” and
“bug fixes”.  Theref

Re: Special One-Time SRU Handling request for torbrowser-launcher

[Thomas Ward]

Robie,

To cherry pick this would require extensive reverse engineering of the 
code to figure out which pieces apply to the *older* versions of 
torbrowser-launcher.  Unfortunately, since there are no *bugfix* 
releases of torbrowser-launcher upstream and everything is interspersed 
among larger-scale feature changes, this prevents us from easily 
cherrypicking the code.  Essentially, to reverse engineer this patch 
would take much MUCH more time and effort to make functional.


However, we have a second consideration point.  With torbrowser-launcher 
0.3.6, we have a major *upstream* change from Tor Browser itself (which 
is downloaded by torbrowser-launcher and installs it in userspace as Tor 
Browser prefers to live in) which involves the loss of all localization 
packages and one unified package for Tor Browser.  To nitpick *those* 
fixes is equivalent to a large feature change that is well-ingrained in 
the 0.3.5 -> 0.3.6 codebase change, and reverse engineering that from 
what I've attempted to do initially for Tor Browser is a nightmare.


Which leaves us with, really, two choices:

 1. Backport 0.3.6-2 in -updates to the older releases

 2. Won't Fix 277 and other bugs which will make the package 
unusuable (effectively: Critical bugging the older version which a lot 
of people use, because it's "no longer supported").


This is tantamount to Bitcoin from the history where Bitcoin would make 
hard forks or major non-reverse-compatible changes that can't be 
backported and in turn would require the newer version to be backported 
in order for `bitcoin` to even function.  The only difference between 
Bitcoin and torbrowser-launcher (and Tor Browser) is that this is the 
first major *historically breaking* change in upstream Tor Browser that 
prohibits simply 'backporting' these changes.


The two-line fix for launch window is minor, and we could theoretically 
survive that.  However, the URL fix is nontrivial to backport within the 
code, hence the request for a one-time special SRU to backport 0.3.6 to 
all current releases (except 18.04 because that's approaching it's EoSS 
date) in order to make everything function in the currently supported 
releases.



Thomas


On 4/6/23 15:55, Robie Basak wrote:

Hi Thomas,

Thank you for caring for this package in Ubuntu!

I'm not sure I follow why this is difficult to fix by cherry-picking
fixes. It seems to me that there are two bugs mentioned - one which is a
two line fix, and one which refers to upstream URLs changing, which
presumably is a change in a constant somewhere or similar.

Will cherry-picking or rewriting these trivial fixes not be enough to
fix the reported bugs? If not, why not?

Robie

On Sun, Mar 19, 2023 at 07:55:48PM -0400, Thomas Ward wrote:

I'm following up on this today, because Debian finally got off their lazy
butt and uploaded 0.3.6-2 to Debian that addresses the core problems in
Debian.

However, that does not solve the problems for everything in Ubuntu.  With
the blessing of the Release team, I did a sync last night (forced) of
0.3.6-2 from Debian Unstable to Ubuntu Lunar, which addresses
https://bugs.launchpad.net/ubuntu/+source/torbrowser-launcher/+bug/277
in Lunar.

Unfortunately the fix that is applied for this in 0.3.6-2 is interwoven with
all the changes from 0.3.3 to 0.3.6 upstream which includes new features.

I have not heard back from the Release team on this, or the SRU team, so I'm
re-asking this.  Is the SRU / Release team willing to let us do a one-time
backport from Lunar of 0.3.6-2 to the older releases currently supported (to
Bionic but no further backwards)?


Thomas


On 2/1/23 14:26, Thomas Ward wrote:

Hello, release team.


Pursuant to a recent change for torbrowser-launcher and Tor Browser, we
have a little bit of a conundrum that is leading to a one time request for
SRUing the latest `torbrowser-launcher` to all currently supported
releases.

With Tor Browser 12 (TB12 for short here), upstream tor browser no longer
uses locales, requiring folder cleanup from TB12 and download URL changes
in order for things to properly function.  Unfortunately, the code changes
necessary to implement the changes to torbrowser-launcher are not easily
nitpicked and include more than just these fixes, as it has new changes
and such to make it work properly. Refer to
https://bugs.launchpad.net/ubuntu/+source/torbrowser-launcher/+bug/277
as the current bug on this.

Debian is behind on updating upstream, so later today I will be preparing
a package for Lunar that will have a -0ubuntu1 prefix for the latest
upstream version.  That works fine in Lunar.  It also works fine in
Kinetic and in initial tests in Jammy.  I’m installing test environments
for Focal and Bionic.

The problem here is, though, we have a mix of “new features” and “bug
fixes” together – there is no ‘major version bump’ for feature branches
vs. ‘bugfix’ branches, making it a comingled problem of “new features” and
“bug fixes”.  Theref

Re: torbrowser-launcher must be at least version="0.3.6" in repository

[Thomas Ward]

Jorgen,

I'm already working on trying to get this approved for SRU.  The problem 
is it has to go through an MRE and the release and SRU teams have to 
approve it, and I have not yet gotten any response or acceptance from 
the Release Team or the SRU team and my multiple inquiries, if I don't 
hear by end of the week I will be going higher up the tech tree to get 
things acted on.



Thomas


On 3/28/23 09:40, "Jørgen Thomsen" wrote:

The tor browser cannot be installed using the torbrowser-launcher
0.3.3 currently in the ubuntu repo.

1) A number of problems arising from the change of language (e.g.
en-US) to ALL in various file and directory names.

2) A problem with broken signature verification is also present from
gpgv requiring the trusted developer key in a trustedkeys.kbx file,
which is non-existant and not created.
trustdb.gpg is the normal file for gpg and the developer key should be
entered into this.


Venlig hilsen
Jørgen Thomsen




--
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: Test RAM

[Thomas De Contes]

Le 23 mars 2023 à 08:24, FARGET Vincent a écrit :

> Bonjour,
> 
> 
> 
> Oui, il faut créer une clé "multiboot", avec ce type de chose, par exemple 
> "multisystem" :
> 
> https://doc.ubuntu-fr.org/multisystem
> 
> ... ou aussi "Ventoy" :
> 
> https://www.ventoy.net/en/index.html
> 
> 
> Cela vous permet de n'avoir qu'une clé USB avec plusieurs possibilités de 
> Boot (ISO/System).


Merci :-) J'essaierai quand je pourrai.

Merci à tous ceux qui m'ont répondu :-)
(dont plusieurs fois la même chose en privé, d'où l'intérêt de répondre en 
public ;-) ).


> 
> 
> Et oui, il vous faudra une image ISO bootable juste pour/avec Memtest86. 


Pourquoi est-ce que ça n'est plus joint à l'image d'installation Ubuntu, alors 
que ça l'était ?

C'est dommage : ça avait l'avantage qu'il suffisait de penser à la 
réinstallation pour avoir cet outil sous la main, pas besoin de penser à cet 
outil spécifiquement.


-- 
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/


-- 
Liste de diffusion ubuntu-fr ubuntu-fr@lists.ubuntu.com
Pour s'abonner ou se désabonner : 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-fr
Charte de la liste: http://doc.ubuntu-fr.org/groupes/ubuntu-fr-ml/charte

Re: Test RAM

[Thomas De Contes]

Le 22 mars 2023 à 17:17, cont...@baal.fr a écrit :

> bonjour,
> 
> 
> c'était memtest x86
> 
> 
> https://www.memtest86.com/


Merci, oui ça correspond à mes souvenirs :-)

Est-ce que memtest a été sur les supports d'installation d'Ubuntu puis en a été 
supprimé ?
Si oui, pourquoi en a-t-il été supprimé ?

Est-ce que ça veut dire qu'on doit obligatoirement préparer sa clé memtest 
avant que l'ordinateur ne veuille plus démarrer à cause de la corruption de 
données ?

Est-ce qu'on doit prévoir 2 clés USB, une pour la réinstallation d'Ubuntu et 
une pour memtest,
ou est-il possible de mettre les 2 dispositifs sur la même clé ?


> Le 22/03/2023 à 17:02, Thomas De Contes a écrit :
>> Bonjour :-)
>> 
>> 
>> Dans mes souvenirs, il y avait des distributions linux qui contenaient sur 
>> leur support d'installation un dispositif permettant de tester la RAM.
>> 
>> J'aurais voulu l'utiliser parce que là justement j'ai un doute sur ma RAM,
>> mais sur la clé Ubuntu 16 que j'ai sous la main, je ne vois rien qui 
>> ressemble à ça.
>> 
>> Est-ce que ça a disparu,
>> ou bien est-ce que c'est à nouveau disponible avec des versions d'Ubuntu 
>> plus récentes,
>> ou faut-il démarrer en mode "essayer Ubuntu" et aller chercher l'outil à un 
>> endroit précis ?

-- 
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/


-- 
Liste de diffusion ubuntu-fr ubuntu-fr@lists.ubuntu.com
Pour s'abonner ou se désabonner : 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-fr
Charte de la liste: http://doc.ubuntu-fr.org/groupes/ubuntu-fr-ml/charte

[Bug 1998834] Re: [BPO] memtest86+/6.10-2 to Jammy

[Thomas Ward]

@ddstreet While I agree in principle, when something changes to adhere
to EFI spec, that's a pretty significant change.  And saves us having to
do the approval *twice*.  I don't disagree this isn't Fantu's fault, but
it shouldn't be much more difficult for them to get -4 into their PPA
and then us sponsor it up to -backports here (with our blessing and no
additional review needed).

That is, if Fantu can put a backported 6.10-4 into the PPA and then you
sponsor it to -backports ddstreet you can Just Do It with the approval.

-- 
You received this bug notification because you are a member of Ubuntu
Backporters, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1998834

Title:
  [BPO] memtest86+/6.10-2 to Jammy

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/memtest86+/+bug/1998834/+subscriptions


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

[Bug 1998834] Re: [BPO] memtest86+/6.10-2 to Jammy

[Thomas Ward]

The only reason I'm going to reject this is that there's changes in -3
and -4 in Lunar now which update to match EFI spec.

Can you do a reupload / sponsor of -4 from Lunar to backports here for
Jammy?

Attached are the -3 and -4 changelog from Lunar / Debian (because it was
synced)


emtest86+ (6.10-4) unstable; urgency=medium

  * Update README.Debian with renamed 32bit files.

 -- Felix Zielcke   Sat, 11 Feb 2023 11:16:22 +0100

memtest86+ (6.10-3) unstable; urgency=medium

  * Rename 32bit files (x32 -> ia32) to match EFI Specification. Thanks
to Jonas Stalder for the hint.

 -- Felix Zielcke   Sat, 11 Feb 2023 10:43:09 +0100

-- 
You received this bug notification because you are a member of Ubuntu
Backporters, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1998834

Title:
  [BPO] memtest86+/6.10-2 to Jammy

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/memtest86+/+bug/1998834/+subscriptions


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

Test RAM

[Thomas De Contes]

Bonjour :-)


Dans mes souvenirs, il y avait des distributions linux qui contenaient sur leur 
support d'installation un dispositif permettant de tester la RAM.

J'aurais voulu l'utiliser parce que là justement j'ai un doute sur ma RAM,
mais sur la clé Ubuntu 16 que j'ai sous la main, je ne vois rien qui ressemble 
à ça.

Est-ce que ça a disparu,
ou bien est-ce que c'est à nouveau disponible avec des versions d'Ubuntu plus 
récentes,
ou faut-il démarrer en mode "essayer Ubuntu" et aller chercher l'outil à un 
endroit précis ?


-- 
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/


-- 
Liste de diffusion ubuntu-fr ubuntu-fr@lists.ubuntu.com
Pour s'abonner ou se désabonner : 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-fr
Charte de la liste: http://doc.ubuntu-fr.org/groupes/ubuntu-fr-ml/charte

RE: dxf2gcode package is looking a bit dusty

[Thomas Ward]

In actuality, the current version is 20191025-2 from Debian synced into Lunar 
during a time period of which between 2018-04-24 the package was last updated 
and now a newer update made in November of 2022.

"dusty" only applies to where the version is the older 20190925-4 version from 
2018, and during the time between 2018 and 2022 the package remained in ubuntu 
because it was synced from Unstable and did not get updated then.

There remains cases that this package is not maintained consistently in Debian 
namely due to the fact that upstream doesn't seem to regularly produce code 
versions for updating.  If you need the newer version you might want to 
consider updating to the 23.04 release when it's out.  Otherwise you'll have to 
stick with the 2017 package version that is available in the version of Ubuntu 
you are using.


Thomas


-Original Message-
From: Ubuntu-devel-discuss  On 
Behalf Of ubun...@skewray.com
Sent: Monday, March 13, 2023 8:20 PM
To: ubuntu-devel-discuss@lists.ubuntu.com
Subject: dxf2gcode package is looking a bit dusty

The dxf2gcode was last built in 2017.  Maybe time for a refresh?


-- 
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: Special One-Time SRU Handling request for torbrowser-launcher

[Thomas Ward]

I'm following up on this today, because Debian finally got off their 
lazy butt and uploaded 0.3.6-2 to Debian that addresses the core 
problems in Debian.


However, that does not solve the problems for everything in Ubuntu.  
With the blessing of the Release team, I did a sync last night (forced) 
of 0.3.6-2 from Debian Unstable to Ubuntu Lunar, which addresses 
https://bugs.launchpad.net/ubuntu/+source/torbrowser-launcher/+bug/277 
in Lunar.


Unfortunately the fix that is applied for this in 0.3.6-2 is interwoven 
with all the changes from 0.3.3 to 0.3.6 upstream which includes new 
features.


I have not heard back from the Release team on this, or the SRU team, so 
I'm re-asking this.  Is the SRU / Release team willing to let us do a 
one-time backport from Lunar of 0.3.6-2 to the older releases currently 
supported (to Bionic but no further backwards)?



Thomas


On 2/1/23 14:26, Thomas Ward wrote:


Hello, release team.


Pursuant to a recent change for torbrowser-launcher and Tor Browser, 
we have a little bit of a conundrum that is leading to a one time 
request for SRUing the latest `torbrowser-launcher` to all currently 
supported releases.


With Tor Browser 12 (TB12 for short here), upstream tor browser no 
longer uses locales, requiring folder cleanup from TB12 and download 
URL changes in order for things to properly function.  Unfortunately, 
the code changes necessary to implement the changes to 
torbrowser-launcher are not easily nitpicked and include more than 
just these fixes, as it has new changes and such to make it work 
properly. Refer to 
https://bugs.launchpad.net/ubuntu/+source/torbrowser-launcher/+bug/277 
as the current bug on this.


Debian is behind on updating upstream, so later today I will be 
preparing a package for Lunar that will have a -0ubuntu1 prefix for 
the latest upstream version.  That works fine in Lunar.  It also works 
fine in Kinetic and in initial tests in Jammy.  I’m installing test 
environments for Focal and Bionic.


The problem here is, though, we have a mix of “new features” and “bug 
fixes” together – there is no ‘major version bump’ for feature 
branches vs. ‘bugfix’ branches, making it a comingled problem of “new 
features” and “bug fixes”.  Therefore, I’d like to request a one-time 
exception for SRU processes to accept the same version packaged for 
each release using Lunar as a base, and adjusting the packaging as 
needed accordingly for older releases.  That is, this will be an SRU, 
but it will accept the ‘new features’ that’re part of 
torbrowser-launcher that were not present in Bionic or Focal but are 
present in later releases.


Most of the ‘feature’ changes allow choosing additional options, etc. 
but nothing that as far as I can tell changes the core functionality 
of the package.


I’m happy to discuss this further with the SRU and Release teams (IRC 
is always a way to reach me heh), but given the complexities of 
including the fixes and changes just to make tor browser 12 work with 
the older launchers, it’d make more sense and ease of fixing this 
“breaks the launcher tool entirely” issue by simply taking the current 
version and making it match in the entire packaging structure.


I’m happy to spearhead this, but I wanted to put this to the Release 
Team and the SRU team for consideration before I go through the 
process of building all this for the SRU/MRE/Version Bump processes as 
well.


A full changelog upstream is available on their GitHub - 
https://github.com/micahflee/torbrowser-launcher


Thomas

LP: https://launchpad.net/~teward

Ubuntu Core Developer

-- 
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: Special One-Time SRU Handling request for torbrowser-launcher

[Thomas Ward]

I'm following up on this today, because Debian finally got off their 
lazy butt and uploaded 0.3.6-2 to Debian that addresses the core 
problems in Debian.


However, that does not solve the problems for everything in Ubuntu.  
With the blessing of the Release team, I did a sync last night (forced) 
of 0.3.6-2 from Debian Unstable to Ubuntu Lunar, which addresses 
https://bugs.launchpad.net/ubuntu/+source/torbrowser-launcher/+bug/277 
in Lunar.


Unfortunately the fix that is applied for this in 0.3.6-2 is interwoven 
with all the changes from 0.3.3 to 0.3.6 upstream which includes new 
features.


I have not heard back from the Release team on this, or the SRU team, so 
I'm re-asking this.  Is the SRU / Release team willing to let us do a 
one-time backport from Lunar of 0.3.6-2 to the older releases currently 
supported (to Bionic but no further backwards)?



Thomas


On 2/1/23 14:26, Thomas Ward wrote:


Hello, release team.


Pursuant to a recent change for torbrowser-launcher and Tor Browser, 
we have a little bit of a conundrum that is leading to a one time 
request for SRUing the latest `torbrowser-launcher` to all currently 
supported releases.


With Tor Browser 12 (TB12 for short here), upstream tor browser no 
longer uses locales, requiring folder cleanup from TB12 and download 
URL changes in order for things to properly function.  Unfortunately, 
the code changes necessary to implement the changes to 
torbrowser-launcher are not easily nitpicked and include more than 
just these fixes, as it has new changes and such to make it work 
properly. Refer to 
https://bugs.launchpad.net/ubuntu/+source/torbrowser-launcher/+bug/277 
as the current bug on this.


Debian is behind on updating upstream, so later today I will be 
preparing a package for Lunar that will have a -0ubuntu1 prefix for 
the latest upstream version.  That works fine in Lunar.  It also works 
fine in Kinetic and in initial tests in Jammy.  I’m installing test 
environments for Focal and Bionic.


The problem here is, though, we have a mix of “new features” and “bug 
fixes” together – there is no ‘major version bump’ for feature 
branches vs. ‘bugfix’ branches, making it a comingled problem of “new 
features” and “bug fixes”.  Therefore, I’d like to request a one-time 
exception for SRU processes to accept the same version packaged for 
each release using Lunar as a base, and adjusting the packaging as 
needed accordingly for older releases.  That is, this will be an SRU, 
but it will accept the ‘new features’ that’re part of 
torbrowser-launcher that were not present in Bionic or Focal but are 
present in later releases.


Most of the ‘feature’ changes allow choosing additional options, etc. 
but nothing that as far as I can tell changes the core functionality 
of the package.


I’m happy to discuss this further with the SRU and Release teams (IRC 
is always a way to reach me heh), but given the complexities of 
including the fixes and changes just to make tor browser 12 work with 
the older launchers, it’d make more sense and ease of fixing this 
“breaks the launcher tool entirely” issue by simply taking the current 
version and making it match in the entire packaging structure.


I’m happy to spearhead this, but I wanted to put this to the Release 
Team and the SRU team for consideration before I go through the 
process of building all this for the SRU/MRE/Version Bump processes as 
well.


A full changelog upstream is available on their GitHub - 
https://github.com/micahflee/torbrowser-launcher


Thomas

LP: https://launchpad.net/~teward

Ubuntu Core Developer

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

Re: [ubuntu-studio-devel] Lowlatency Kernel is behind in Ubuntu Studio

[Thomas Ward]

A general reminder to *everyone* with my Community Council hat on:

Whether you are Canonical, an Ubuntu Flavor team member, or just a 
general community member, if you feel yourself starting to get hostile / 
aggressive in tone, step back and take a breather.


There are an increasing number of times I myself see conflict between 
people - whether it involves Canonical employees, Ubuntu Flavor teams, 
or otherwise - spilling into the lists, and it seems people are starting 
to skirt against CoC with those cases.


My advice is, on this case, Dimitri and Erich, both of you can go take a 
breather for a bit, and calm a little before returning to this.


(I'm not a fan of seeing this level of dissent / aggressiveness between 
people on the public lists, and as Philipp and Mauro at the Canonical 
Community Team know, this is an issue that seems to be becoming systemic 
and we have to remind people about the CoC and how to be nice towards 
others, or at least be constructive without coming off as hostile).



Thomas Ward
Ubuntu Community Council Member

On 3/13/23 14:48, Steve Langasek wrote:

On Mon, Mar 13, 2023 at 06:03:00PM +, Dimitri John Ledkov wrote:

We pushed 6.1 out, and migrated, on generic only, to migrate lots of
packages in proposed, specifically nvidia & everything entangled with
it, and thus unblock autopkgtesting of all the userspace packages
which were otherwise failing on v5.19. There is no intention to port
all flavours to 6.1.

Again, this is one of the reasons we had do miss testing week among another

it was a mistake to skip testing week. you should have tested ubuntu
studio during the testing week like all the other flavours did. As
there are a lot of changes in lunar, that landed and affect ubuntu
studio. For example, all cloud images which use various cloud kernel
flavours, based on v5.19 did participate.
Can you explain who made the call to skip testing week? as to me, it
seemed, it's a requirement to release a flavour. Is studio going to
skip Lunar release?

Testing week is not a release-team-driven activity and flavor engagement in
it has no bearing on a flavor's eligibility for inclusion in a stable
release.

Flavors are required to hit a beta milestone and a release milestone.  How
they conduct their activities to ensure that these milestones are releasable
is for them to decide.




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

Re: Lowlatency Kernel is behind in Ubuntu Studio

[Thomas Ward]

A general reminder to *everyone* with my Community Council hat on:

Whether you are Canonical, an Ubuntu Flavor team member, or just a 
general community member, if you feel yourself starting to get hostile / 
aggressive in tone, step back and take a breather.


There are an increasing number of times I myself see conflict between 
people - whether it involves Canonical employees, Ubuntu Flavor teams, 
or otherwise - spilling into the lists, and it seems people are starting 
to skirt against CoC with those cases.


My advice is, on this case, Dimitri and Erich, both of you can go take a 
breather for a bit, and calm a little before returning to this.


(I'm not a fan of seeing this level of dissent / aggressiveness between 
people on the public lists, and as Philipp and Mauro at the Canonical 
Community Team know, this is an issue that seems to be becoming systemic 
and we have to remind people about the CoC and how to be nice towards 
others, or at least be constructive without coming off as hostile).



Thomas Ward
Ubuntu Community Council Member

On 3/13/23 14:48, Steve Langasek wrote:

On Mon, Mar 13, 2023 at 06:03:00PM +, Dimitri John Ledkov wrote:

We pushed 6.1 out, and migrated, on generic only, to migrate lots of
packages in proposed, specifically nvidia & everything entangled with
it, and thus unblock autopkgtesting of all the userspace packages
which were otherwise failing on v5.19. There is no intention to port
all flavours to 6.1.

Again, this is one of the reasons we had do miss testing week among another

it was a mistake to skip testing week. you should have tested ubuntu
studio during the testing week like all the other flavours did. As
there are a lot of changes in lunar, that landed and affect ubuntu
studio. For example, all cloud images which use various cloud kernel
flavours, based on v5.19 did participate.
Can you explain who made the call to skip testing week? as to me, it
seemed, it's a requirement to release a flavour. Is studio going to
skip Lunar release?

Testing week is not a release-team-driven activity and flavor engagement in
it has no bearing on a flavor's eligibility for inclusion in a stable
release.

Flavors are required to hit a beta milestone and a release milestone.  How
they conduct their activities to ensure that these milestones are releasable
is for them to decide.




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

RE: unixodbc-dev 2.3.11 seems broken

[Thomas Ward]

Unfortunately here your choices are limited.  The ODBC from Microsoft is 
different than the one in the repos and the two packages conflict.

>From my experience you will have to pick one or the other - use Microsoft's 
>packaged ODBC and no headers, or use the one in the repos with the headers and 
>not use Microsoft.



Sent from my Galaxy



 Original message 
From: Robert Ayrapetyan 
Date: 2/11/23 18:56 (GMT-05:00)
To: ubuntu-devel-discuss@lists.ubuntu.com
Subject: Re: unixodbc-dev 2.3.11 seems broken

Seems it comes as part of msodbcsql18 from official MS repository...

On Sat, Feb 11, 2023 at 3:46 PM Robert Ayrapetyan 
mailto:robert.ayrapet...@gmail.com>> wrote:
You're right, it came from:

https://packages.microsoft.com/ubuntu/20.04/prod focal/main amd64 unixodbc-dev 
amd64 2.3.11 [42.1 kB]

What's the best way to install the right package (2.3.11-2) without removing MS 
repo?

On Sat, Feb 11, 2023 at 3:09 PM Colin Watson 
mailto:cjwat...@ubuntu.com>> wrote:
On Sat, Feb 11, 2023 at 10:13:13AM -0800, Robert Ayrapetyan wrote:
> # lsb_release -a
> No LSB modules are available.
> Distributor ID: Ubuntu
> Description:Ubuntu 20.04.5 LTS
> Release:20.04
> Codename:   focal
>
>
> # apt show unixodbc-dev
> Package: unixodbc-dev
> Version: 2.3.11

This is not a package that comes from Ubuntu 20.04, and in fact it
doesn't appear to have come from any version of Ubuntu at all (versions
of unixodbc-dev provided by Ubuntu have some kind of suffix after the
upstream version number - for example, the version in Ubuntu 22.10 is
2.3.11-2).  Where did you get it from?  The package is clearly broken,
but that isn't an Ubuntu problem - perhaps you should reinstall the
working version from Ubuntu.

--
Colin Watson (he/him)  
[cjwat...@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
-- 
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

Special One-Time SRU Handling request for torbrowser-launcher

[Thomas Ward]

Hello, release team.

Pursuant to a recent change for torbrowser-launcher and Tor Browser, we have a 
little bit of a conundrum that is leading to a one time request for SRUing the 
latest `torbrowser-launcher` to all currently supported releases.

With Tor Browser 12 (TB12 for short here), upstream tor browser no longer uses 
locales, requiring folder cleanup from TB12 and download URL changes in order 
for things to properly function.  Unfortunately, the code changes necessary to 
implement the changes to torbrowser-launcher are not easily nitpicked and 
include more than just these fixes, as it has new changes and such to make it 
work properly.  Refer to 
https://bugs.launchpad.net/ubuntu/+source/torbrowser-launcher/+bug/277 as 
the current bug on this.

Debian is behind on updating upstream, so later today I will be preparing a 
package for Lunar that will have a -0ubuntu1 prefix for the latest upstream 
version.  That works fine in Lunar.  It also works fine in Kinetic and in 
initial tests in Jammy.  I'm installing test environments for Focal and Bionic.

The problem here is, though, we have a mix of "new features" and "bug fixes" 
together - there is no  'major version bump' for feature branches vs. 'bugfix' 
branches, making it a comingled problem of "new features" and "bug fixes".  
Therefore, I'd like to request a one-time exception for SRU processes to accept 
the same version packaged for each release using Lunar as a base, and adjusting 
the packaging as needed accordingly for older releases.  That is, this will be 
an SRU, but it will accept the 'new features' that're part of 
torbrowser-launcher that were not present in Bionic or Focal but are present in 
later releases.

Most of the 'feature' changes allow choosing additional options, etc. but 
nothing that as far as I can tell changes the core functionality of the package.

I'm happy to discuss this further with the SRU and Release teams (IRC is always 
a way to reach me heh), but given the complexities of including the fixes and 
changes just to make tor browser 12 work with the older launchers, it'd make 
more sense and ease of fixing this "breaks the launcher tool entirely" issue by 
simply taking the current version and making it match in the entire packaging 
structure.

I'm happy to spearhead this, but I wanted to put this to the Release Team and 
the SRU team for consideration before I go through the process of building all 
this for the SRU/MRE/Version Bump processes as well.

A full changelog upstream is available on their GitHub - 
https://github.com/micahflee/torbrowser-launcher



Thomas
LP: https://launchpad.net/~teward
Ubuntu Core Developer
-- 
Ubuntu-release mailing list
Ubuntu-release@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-release

Forbidden Packages: Add "core SSL libraries" to Forbidden list

[Thomas Ward]

Today, this backport request came in for OpenSSL:

https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2003903

This request was made so that allowing SSL_OP_LEGACY_SERVER_CONNECT to 
actually work would be available in -backports.


Any time that OpenSSL comes up in my radar for sponsors or backporting 
it ends up making me ask the Security team on their opinion because any 
patches to OpenSSL from Security won't make it to -backports and because 
of ABI/API changes that sneak in with microreleases to core SSL 
libraries (openssl, nss, gnutls, ...).


With this discussion brought up, it was discussed in #ubuntu-devel with 
me pinging both Dan Streetman and Mattia Rizzolo in IRC, Mattia chimed 
in on the discussion and with our discussion there, myself and Mattia 
agreed that, due to security reasons and concerns of ABI breakage in 
packages across the board, as well as the fact -backports doesn't get 
Security Team coverage there, we were going to add a category of "core 
SSL libraries" (with examples) to the Forbidden Packages section in 
backport policies.


Right now this has a +2 on this - myself and Mattia in support of this, 
and with this we made the change as that gives a majority decision 
currently among the Backporters team.  Additionally, Security wanted to 
make aware that they wouldn't want to see OpenSSL land in -backports 
because of the huge integration that OpenSSL has which could introduce 
many breakages in non-backports when a backported OPenSSL or such is 
used for libraries.


I've made this revision in the backports policies because myself and 
Mattia had an agreement in IRC on this, we can revert this in a future 
discussion if necessary.  Per policy, this is the note for the 
discussion here on the ML.



Thomas Ward

Backporters Member


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

[Bug 2003903] Re: [BPO] openssl/3.0.5-2ubuntu2 from kinetic

[Thomas Ward]

I've discussed this with mapreri who is another person on the
backporters team.

Given the API/ABI changes that happen during OpenSSL microreleases that
break packages integrations AND that this will add a security delta
(-backports doesn't receive Security Team support so if they change and
patch a CVE in -security or -updates it remains unpatched in -backports
which introduces a significant Security risk.

Additionally, if it's only 3 or 4 commits to fix
SSL_OP_LEGACY_SERVER_CONNECT then you need to follow the SRU process,
not the Backports process.

Rejecting this backport as "Won't Fix" due to the aforementioned
reasons.  Additionally, the Backporters Team are going to blacklist
`openssl` for backport requests unless it comes from Security at this
time.

** Changed in: openssl (Ubuntu)
   Status: New => Won't Fix

-- 
You received this bug notification because you are a member of Ubuntu
Backporters, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/2003903

Title:
  [BPO] openssl/3.0.5-2ubuntu2 from kinetic

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2003903/+subscriptions


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

[Bug 2003903] Re: [BPO] openssl/3.0.5-2ubuntu2 from kinetic

[Thomas Ward]

Mark, are you asking this to be backported in -backports or in -updates
and -security?  This is one of the packages that if we do this in
-backports any security patches applied by the Security team for OpenSSL
in -security and -updates would be ignored with the higher version of
this in -backports.

-- 
You received this bug notification because you are a member of Ubuntu
Backporters, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/2003903

Title:
  [BPO] openssl/3.0.5-2ubuntu2 from kinetic

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2003903/+subscriptions


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

[Bug 2003903] Re: [BPO] openssl/3.0.5-2ubuntu2 from kinetic

[Thomas Ward]

OpenSSL is one of those tricky things out there I would like to get a
Security insight for before we do any kind of backporting of it.
There's other things this could impact, backports or not.

-- 
You received this bug notification because you are a member of Ubuntu
Backporters, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/2003903

Title:
  [BPO] openssl/3.0.5-2ubuntu2 from kinetic

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2003903/+subscriptions


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

Re: move to deb822 sources in ubuntu:lunar docker image

[Thomas Bechtold]

Hi Julian,

On 12.01.23 17:54, Julian Andres Klode wrote:

(resend with proper subject, sigh, mutt mishaps)

As part of deb822 sources file enablement, the specification
states a MVP for 23.04 to move sources.list to sources.list.d/
ubuntu.sources (in deb822 format obviously) inside Docker images.

While we're still porting aptsources to support those, I think we
can go ahead and do that now, we don't ship python-apt in docker
images anyway, and software-properties is really the only thing
broken by that change afaict.

For comparison, we had debian:unstable using a
sources.list.d/debian.sources for months now and it's
stable.

So I'd ask tianon to turn the switch next week if nobody
has strong objections.


What switch is that that Tianon can turn?. the tarballs to create the 
ubuntu:* OCI base images are built with livecd-rootfs/live-build. The 
whole process to create the images in under the control of the ROCKs 
team (and previously the CPC team).
So my understanding is, that we would need to adjust live-build and/or 
livecd-rootfs to use the deb822 format. And if we do that, would

we also need to adjust launchpad-buildd to handle the new format, too?

Best,

Tom


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

RE: libapache2-mod-shib2 package for Ubuntu 22.04

[Thomas Ward]

If the package is not yet in 22.04 it is unlikely to land except via Backports 
which is its own process.



Sent from my Galaxy



 Original message 
From: Kent Kutan 
Date: 1/14/23 16:34 (GMT-05:00)
To: ubuntu-devel-discuss@lists.ubuntu.com
Subject: libapache2-mod-shib2 package for Ubuntu 22.04

Good evening,

I was wondering if you have a planned release date for the libapache2-mod-shib2 
package for Ubuntu 22.04 (Jammy Jellyfish).

Thanks,

Kent

-- 
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 2002211] Re: [BPO] python-websockets/10.2-1 from kinetic

[Thomas Ward]

Sponsored to -backports.  I require at least one other backporter to
look at and OK this for acceptance into backports however.

Removing sponsors.

-- 
You received this bug notification because you are a member of Ubuntu
Backporters, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/2002211

Title:
  [BPO] python-websockets/10.2-1 from kinetic

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python-websockets/+bug/2002211/+subscriptions


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

RE: Getting Invalid version exception during apt update

[Thomas Ward]

You already got a response on this thread from Colin, quoted below:


On Tue, Jan 03, 2023 at 12:04:34PM +0530, probal basak wrote:

> I am getting the below exception while trying to issue apt update:

> Getting this issue since last week. Previously the same thing used to

> work perfectly fine.



This is a bug in appimage-builder.  As you can see from the fact that it's 
installed in /usr/local, it's not supplied by Ubuntu.



The bug is that it's apparently trying to use the Python packaging.version 
library to parse and compare the version numbers of Ubuntu packages.  Ubuntu 
package versions are not compatible with Python package versions, and it is 
incorrect to use Python's packaging.version library to do this job.



It looks like this bug was fixed in

https://github.com/AppImageCrafters/appimage-builder/pull/281, although it 
doesn't seem that there's been a release since that fix landed.  I don't know 
how best to advise you to apply that fix to your system, but presumably you 
installed this program yourself and so have some idea of how best to upgrade it.



--

Colin Watson (he/him)  [cjwat...@ubuntu.com]


From: Ubuntu-devel-discuss  On 
Behalf Of probal basak
Sent: Tuesday, January 3, 2023 1:36 AM
To: ubuntu-devel-discuss@lists.ubuntu.com
Subject: Getting Invalid version exception during apt update

Hello Team,

I am getting the below exception while trying to issue apt update:
Getting this issue since last week. Previously the same thing used to work 
perfectly fine.

Get:13 http://security.ubuntu.com/ubuntu focal-security/restricted amd64 
Packages [1385 kB]
Fetched 17.1 MB in 5s (3617 kB/s)
Reading package lists... Done
Traceback (most recent call last):
  File "/usr/local/bin/appimage-builder", line 8, in 
sys.exit(__main__())
  File "/usr/local/lib/python3.8/dist-packages/appimagebuilder/__main__.py", 
line 58, in __main__
invoker.execute(commands)
  File "/usr/local/lib/python3.8/dist-packages/appimagebuilder/invoker.py", 
line 41, in execute
command()
  File 
"/usr/local/lib/python3.8/dist-packages/appimagebuilder/commands/apt_deploy.py",
 line 46, in __call__
deployed_packages = apt_deploy.deploy(
  File 
"/usr/local/lib/python3.8/dist-packages/appimagebuilder/modules/deploy/apt/deploy.py",
 line 41, in deploy
self._prepare_apt_venv()
  File 
"/usr/local/lib/python3.8/dist-packages/appimagebuilder/modules/deploy/apt/deploy.py",
 line 57, in _prepare_apt_venv
apt_core_packages = self._remove_old_packages(apt_core_packages)
  File 
"/usr/local/lib/python3.8/dist-packages/appimagebuilder/modules/deploy/apt/deploy.py",
 line 113, in _remove_old_packages
if package > latest_packages[pkg_tuple]:
  File 
"/usr/local/lib/python3.8/dist-packages/appimagebuilder/modules/deploy/apt/package.py",
 line 79, in __gt__
return version.parse(self.version) > version.parse(other.version)
  File "/usr/local/lib/python3.8/dist-packages/packaging/version.py", line 52, 
in parse
return Version(version)
  File "/usr/local/lib/python3.8/dist-packages/packaging/version.py", line 197, 
in __init__
raise InvalidVersion(f"Invalid version: '{version}'")
packaging.version.InvalidVersion: Invalid version: '1.19.7ubuntu3'


Can you please help me to understand what the issue is about? And how to 
resolve this issue please?

Thanks in advance.


--
Thanks,
Probal Basak.
-- 
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 1968076] Re: [BPO] ipmctl with support for CPS hardware

[Thomas Ward]

** Changed in: ipmctl (Ubuntu Focal)
   Status: New => In Progress

-- 
You received this bug notification because you are a member of Ubuntu
Backporters, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1968076

Title:
  [BPO] ipmctl with support for CPS hardware

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ipmctl/+bug/1968076/+subscriptions


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

RE: Tomcat9 - Ubuntu 20.04 x64

[Thomas Ward]

FYI that's MOST vulnerability scanners.  Most of them do not have privileged 
access nor the database of ubuntu patch info in them so report solely on the 
exposed version number and thats it.  It leads to a lot of false positives and 
then questions like these.  ;)



Sent from my Galaxy



 Original message 
From: Brad Turnbough 
Date: 11/21/22 16:15 (GMT-05:00)
To: Robie Basak 
Cc: ubuntu-devel-discuss@lists.ubuntu.com
Subject: RE: Tomcat9 - Ubuntu 20.04 x64

This is exactly what I was looking for.  The vulnerability was addressed in 
v9.0.31 of the package.  Nessus must look at the apache tomcat version and not 
take into consideration

Thanks for your very helpful info.  Much appreciated.




Thank you,

Brad Turnbough
Senior Technology Analyst

P: 309.272.2739 F: 309.272.2839

www.betterbanks.com
www.glasfordbank.com



NOTICE: The information contained in this email and any document attached 
hereto is intended only for the named recipient(s). If you are not the intended 
recipient, nor the employee or agent responsible for delivering this message in 
confidence to the intended recipient(s), you are hereby notified that you have 
received this transmittal in error, and any review, dissemination, distribution 
or copying of this transmittal or its attachments is strictly prohibited. If 
you have received this transmittal and/or attachments in error, please notify 
me immediately by reply e-mail and then delete this message, including any 
attachments.

www.statestreetbank.com-Original
 Message-
From: Robie Basak 
Sent: Tuesday, November 15, 2022 10:00 AM
To: Brad Turnbough 
Cc: ubuntu-devel-discuss@lists.ubuntu.com
Subject: Re: Tomcat9 - Ubuntu 20.04 x64

Hi,

On Mon, Nov 14, 2022 at 04:00:22PM +, Brad Turnbough wrote:
> Ran a nessus scan against the box and am being told that verion 9.0.31 is 
> vulnerable to a DoS attack and that I need to upgrade to >=9.0.36.  Problem 
> is, that version isn't available in the Ubuntu repos.
>
> Can someone look into getting this package updated in order to resolve this 
> vulnerability?

Please see: https://wiki.ubuntu.com/SecurityTeam/FAQ#Versions

If after understanding that you still think the package is vulnerable, you need 
to identify a specific CVE.

Once you have that, you can search for the status of a specific CVE at 
https://ubuntu.com/security/cves.

Hope that helps,

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

[Bug 1997189] Re: [BPO] elfutils/0.188-1 from Lunar

[Thomas Ward]

> I intend to update Ubuntu's debuginfod instance to use this new
package in the near future.

By "update" do you mean SRU or via Backports?  If you are not going to
be doing this via Backports, then I would suggest that you hunt an SRU
on the sole basis that mixing and matching SRU/Backports makes things a
"Well, why do we need this?" situation on both Backports and Stable
Release Updates.

-- 
You received this bug notification because you are a member of Ubuntu
Backporters, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1997189

Title:
   [BPO] elfutils/0.188-1 from Lunar

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/elfutils/+bug/1997189/+subscriptions


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

Thunderbird update

[Thomas Wanderer]

Dear maintainers,

could you please update to Thunderbid 102.4?

This author of the very important plugin TBSync to sync Thundbird with 
Exchange ActiveSync (EAS) can't release his plugin for 102.2.2 because 
of a bug in Thunderbird leading to data loss. We would need the minor 
update to 102.4


More about this here:
https://github.com/jobisoft/TbSync/issues/630#issuecomment-1308820475

There are many users with this quite essential plugin who can't get 
their data synced anymore since a few weeks.


Thanks for releasing an update very soon

Thomas

--
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 1995967] Re: [BPO] qt6-base/6.2.4+dfsg-10 from kinetic

[Thomas Ward]

This sounds like something that should be an SRU not a backport.
Especially since theres an open bug on this and a patch exists.

-- 
You received this bug notification because you are a member of Ubuntu
Backporters, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1995967

Title:
  [BPO] qt6-base/6.2.4+dfsg-10 from kinetic

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/qt6-base/+bug/1995967/+subscriptions


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

[Bug 1992163] Re: [BPO] man-db/2.10.2-1 from jammy

[Thomas Ward]

Mattia:  Big change or not, SRU team might let it through because it's a
*performance bug fix*.  This alone is not sufficient, in my opinion, for
a backport, when an SRU is the process it should be going through
because it fixes a bug - a performance one, granted, but it's still
SRUable I believe.

-- 
You received this bug notification because you are a member of Ubuntu
Backporters, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1992163

Title:
  [BPO] man-db/2.10.2-1 from jammy

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/man-db/+bug/1992163/+subscriptions


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

[Bug 1992163] Re: [BPO] man-db/2.10.2-1 from jammy

[Thomas Ward]

Is there a reason the fixes can't be cherrypicked and then SRU'd to fix
this issue?  Backports is typically NOT the way to get fixes for issues
into already stable releases.

** Changed in: man-db (Ubuntu)
   Status: New => Incomplete

-- 
You received this bug notification because you are a member of Ubuntu
Backporters, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1992163

Title:
  [BPO] man-db/2.10.2-1 from jammy

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/man-db/+bug/1992163/+subscriptions


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

[Bug 1990382] Re: [BPO] libreoffice 7.3.6 for bionic

[Thomas Ward]

Not all Autopkgtests have run and therefore you cannot claim they are
all passing.  This is marked Incomplete until you have provided evidence
that all the autopkgtests and such clear for all supported
architectures.

** Changed in: libreoffice (Ubuntu Bionic)
   Status: In Progress => Incomplete

-- 
You received this bug notification because you are a member of Ubuntu
Backporters, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1990382

Title:
  [BPO] libreoffice 7.3.6 for bionic

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1990382/+subscriptions


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

[Bug 1989418] Re: [BPO] libreoffice 7.3.6 for focal

[Thomas Ward]

OK just doing due diligence.

Approved for backports pocket, it'll need to build and publish then
should be available afterwards.

** Changed in: libreoffice (Ubuntu Focal)
   Status: In Progress => Fix Committed

-- 
You received this bug notification because you are a member of Ubuntu
Backporters, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1989418

Title:
   [BPO] libreoffice 7.3.6 for focal

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1989418/+subscriptions


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

[Bug 1989418] Re: [BPO] libreoffice 7.3.6 for focal

[Thomas Ward]

I'm confused, are you asking for a backport to the backports pocket or
an SRU?  The bug refers to SRU in multiple places.

Backports in the backports pocket are NOT SRUs so its critical to
identify which process and goal you have in mind - SRU or backport.

-- 
You received this bug notification because you are a member of Ubuntu
Backporters, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1989418

Title:
   [BPO] libreoffice 7.3.6 for focal

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1989418/+subscriptions


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

Re: Package Update for Ubuntu

[Thomas Ward]

To which SSL issues are you referring, in which Ubuntu releases?

There is a fix in the works for the SSL EOF client issues, if you have a 
specific CVE or information you need to link here please. CVEs are 
typically patched by the Security Team without any change to the actual 
version of the program installed, and instead relying on nitpicked fixes.




Thomas


On 8/30/22 16:45, Maxime Pietrucci-Blacher wrote:
Good evening, I have come to contact you to find out if the 
nginx-common and nginx-core packages are going to be updated soon, as 
there are many problems with the use of TLS on these two packages as 
they are no longer up to date.
Also, I would like to know if there is a way to fix this independently 
or if it is necessary to wait (an update of the package which seems 
urgent to me, considering the recent CVE).

Thank you for your help,
Maxime Pietrucci-Blacher
-- 
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: rsync - security error

[Thomas Ward]

Alex,

I believe that OP is referring to the last set of CVEs listed here[1] announced 
on the 14th.  So forgive me while I poke the thread with additional 
information.    I think the original ask was about those.

--

CVE-2022-37434 was announced on the 14th.  And is patched already in Ubuntu [2].

CVE-2022-29154 is the second one, and was deemed too intrusive [3] to include 
as a security update for any of the releases at the time of review (see the 
details in the link).



--

Thomas


[1]: https://rsync.samba.org/security.html
[2]: https://ubuntu.com/security/CVE-2022-37434
[3]: https://ubuntu.com/security/CVE-2022-29154



From: Ubuntu-devel-discuss  on 
behalf of Alex Murray 
Sent: Thursday, August 25, 2022 9:52 PM
To: mynek...@mail.de ; ubuntu-devel-discuss@lists.ubuntu.com 

Subject: Re: rsync - security error

Hi

In Ubuntu we generally do not upload new versions of packages once a
particular Ubuntu release is made. Instead when a security bug (CVE) is
announced, if the version of the particular package in that Ubuntu
release is affected, the security team will backport the patch which
fixes the bug to the older version of the package.

As such, there are currently no known CVEs which have not been patched
for rsync in Ubuntu - you can see this by looking at:

https://ubuntu.com/security/cves?q==rsync===

Thanks,
Alex

On Fri, 2022-08-19 at 21:05:42 +0200, mynek...@mail.de wrote:

>
> Hello,
>
> please provide a new version. The current one contains a security bug.
>
> The current one is 3.2.5.
> See: https://rsync.samba.org/
>
> Thank you
>
> --
> 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
-- 
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 1983414] Re: [BPO] dh-python 5.20220403 to focal

[Thomas Ward]

Marking this as Won't Fix because of identified issues and Unit
indicating that this should be withdrawn.

** Changed in: dh-python (Ubuntu Focal)
   Status: Incomplete => Won't Fix

-- 
You received this bug notification because you are a member of Ubuntu
Backporters, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1983414

Title:
  [BPO] dh-python 5.20220403 to focal

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dh-python/+bug/1983414/+subscriptions


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

[Bug 1987356] Re: [BPO] elfutils/0.187-1 from Kinetic

[Thomas Ward]

** Changed in: elfutils (Ubuntu)
   Status: In Progress => Fix Committed

-- 
You received this bug notification because you are a member of Ubuntu
Backporters, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1987356

Title:
  [BPO] elfutils/0.187-1 from Kinetic

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/elfutils/+bug/1987356/+subscriptions


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

[Bug 1984053] Re: [BPO] nala/0.11.1 and socksio/1.0.0-2 from Kinetic Kudu

[Thomas Ward]

Both are in the process of working.  socksio is in backports and
published.  nala is pending publication in backports.

** Changed in: socksio (Ubuntu)
   Status: In Progress => Fix Released

** Changed in: nala (Ubuntu)
   Status: In Progress => Fix Committed

** Changed in: nala (Ubuntu)
 Assignee: Joakim Malmquist (anthr) => (unassigned)

** Changed in: socksio (Ubuntu)
 Assignee: Joakim Malmquist (anthr) => (unassigned)

-- 
You received this bug notification because you are a member of Ubuntu
Backporters, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1984053

Title:
  [BPO] nala/0.11.1 and socksio/1.0.0-2 from Kinetic Kudu

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nala/+bug/1984053/+subscriptions


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

[Bug 1984053] Re: [BPO] nala/0.11.1 and socksio/1.0.0-2 from Kinetic Kudu

[Thomas Ward]

(Backports pocket is a little bit different than AA "NEW" queue)

-- 
You received this bug notification because you are a member of Ubuntu
Backporters, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1984053

Title:
  [BPO] nala/0.11.1 and socksio/1.0.0-2 from Kinetic Kudu

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nala/+bug/1984053/+subscriptions


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

[Bug 1984053] Re: [BPO] nala/0.11.1 and socksio/1.0.0-2 from Kinetic Kudu

[Thomas Ward]

socksio has been accepted but I can also accept nala as well, if it
FTBFS we'll just rerun the build.

-- 
You received this bug notification because you are a member of Ubuntu
Backporters, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1984053

Title:
  [BPO] nala/0.11.1 and socksio/1.0.0-2 from Kinetic Kudu

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nala/+bug/1984053/+subscriptions


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

Re: Core Dev Application

[Thomas Ward]

As of the July 25th DMB meeting, this Core Developer application was 
approved, and we welcome Mattia into the ranks of the Ubuntu Core 
Developers.


Congratulations, Mattia!


Thomas
Ubuntu DMB Member

On 7/13/22 12:13, Mattia Rizzolo wrote:

Hi DMB!

I decided to finally send in my core-dev application.

See https://wiki.ubuntu.com/MattiaRizzolo/CoreDevApplication

I added myself to https://wiki.ubuntu.com/DeveloperMembershipBoard/Agenda
for the next meeting (scheduled on 2022-07-25 16 CEST if I can read the
pages right).





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

Re: New Official Flavor Process Issues (Was Re: Ubuntu Cinnamon Remix packages)

[Thomas Ward]

ou do that wrong consistently in a way that may be against CoC 
especially on public lists, then it becomes a Problem(TM) that may come 
back to bite you.  So as I said in the beginning of my message, take a 
deep breath and relax a little.


If you truly believe that I need to be a core dev,
(CC, DMB) Where did it say you need core-dev?  You don't need to be MOTU 
or Core Dev to have upload rights for a package - just apply via the DMB 
PPU process.  Get the upload rights for what you need specifically in 
the flavor.
then you are saying any community member who wants to create a flavor 
needs to spend YEARS getting to that high of privilege.
(DMB, Core Dev) No, you don't need YEARS to get the privilege of upload 
for the packages you need.  Refer to the PPU application process.
And that is not community friendly at all. I am a student, and I'm 
going to a magnet school in September (a CS school might I add).

(CC) Irrelevant to the point that was raised.
School is going to get more intense and I'm not going to be spending 6 
hours a day on Ubuntu development.
(Personal) I am not employed by Canonical.  The amount of *actual* 
development work I do with Ubuntu nowadays is interspersed among my free 
time and is not easily noticed to the public at large.  And while I may 
not have a ton of uploads going on right now, or a ton of development on 
packages being done here at the moment, most of my energy goes into my 
Full Time job and being paid for things, or going to school like I did 
for university and such did NOT interfere from me putting a couple hours 
a week into Ubuntu.  You don't have to go hard core six hours a day of 
Ubuntu work.  I haven't, and yet I sit on the CC, DMB, and have Core Dev 
rights today after putting a few hours work a week or so at most over 
the course of time in to get the recognition and hats I have.  That 
didn't come from six hours a day of Ubuntu contributions, that came from 
me volunteering time I have when I have it and want to contribute, over 
the course of years, to get to where I am now.  Nobody ever said you 
have to spend 6 hours a day contributing to Ubuntu or any specific 
flavor. Nor have I seen anybody be saying that now.


(DMB) Further, the requirements for PPU are a lot lower to an extent 
than the requirements for MOTU and Core Dev - we still require you to 
understand basic things like how the SRU process works, etc. so you 
don't overstep your rights to upload specific packages, but we also 
focus *only* on the pacakges you have worked on that you're applying for 
in comparison to all your contributions.  So the scope of what is 
assessed is different, and it seems you aren't understanding this.




Again, to you this is hard to understand because you already **have** 
the upload rights.
(CC) Calm down already.  This level of aggressiveness and 
pointedness/stabbing despite other posts in your message here is the 
*wrong way* to approach this, and while we all get this way from time to 
time, there's been **a lot** of this type of frustration voiced by you 
in ways that **do not** get results and get you labeled as an irritant.




Truly, with honesty,
-Josh

*From:* Jeremy Bicha 
*Sent:* Thursday, July 28, 2022 10:20
*To:* eeickme...@ubuntu.com 
*Cc:* Steve Langasek ; 
technical-bo...@lists.ubuntu.com ; 
community-coun...@lists.ubuntu.com 
; itzswirlz2...@outlook.com 
; ubuntu-release@lists.ubuntu.com 

*Subject:* Re: New Official Flavor Process Issues (Was Re: Ubuntu 
Cinnamon Remix packages)

On Thu, Jul 28, 2022 at 9:55 AM  wrote:
> This most certainly is not a hasty escalation. I've been aware of
> Ubuntu Cinnamon Remix for 3 years and in that time, Joshua's intention
> was to make it an official flavor. They have been encouraged to become
> an official flavor since Day 0.

The escalation from my perspective is that it appears to me like y'all
made a request to become an official flavor on Saturday, got a reply
on Sunday, and then invoked the authority of the Ubuntu Community
Council on Wednesday. I don't think that's being fair to the Tech
Board.
(CC) I agree with Jeremy here, the optics of this and the way you 
handled this, Erich, are bad.  Next time, wait for Council quorum on an 
issue before we wave the CC hats around as "oh now this is CC 
escalated", because the optics are just as important as the real 
processes, and you didn't *need* to bring *this* up as a CC issue. You 
could have simply emailed the TB and asked the TB to better document the 
process, and copy the CC for awareness.  This didn't need a CC 
issue/escalation task though, in my opinion, so with my CC hat on, in my 
opinion, you're taking non-consensus actions claiming this needed CC 
intervention.


You can make requests for improvement as an individual developer
without needing to speak on behalf of the Community Council.

Thank you,
Jeremy Bicha




---

Thomas Ward
"The Man o

RE: Questions about openssl in Ubuntu mirrors

[Thomas Ward]

Regarding your first question about why we don’t update directly to newer 
versions, etc.:

Once a version of OpenSSL (or most libraries) is released in Ubuntu, like many 
other pieces of software they’re more or less ‘version locked’.  For the most 
part, this answer on Ask Ubuntu is still more or less accurate: 
https://askubuntu.com/a/151304/10616

*That applies for OpenSSL as well*


Regarding your second question about Xenial:

All Ubuntu releases have a set period of standard support.  For interim non-LTS 
releases, this is 9 months.

For LTS releases, this is five years from the initial release date.  After 
those five years, it leaves the standard support period.  After which, 
Canonical (typically, from my observations) provides Extended Security 
Maintenance coverage through the Ubuntu Advantage for Infrastructure 
subscription support programs.

For Xenial 16.04, the Standard Support period ended in April 2021.  (see Ubuntu 
16.04 LTS (Xenial Xerus) 
released<https://lists.ubuntu.com/archives/ubuntu-announce/2016-April/000207.html>).
  When Standard Support ended, and Xenial entered the Extended Security 
Maintenance period, the standard cadence of the Ubuntu Security Team patching 
items in Xenial moved from the standard xenial-security repositories into the 
Ubuntu Advantage ESM repositories which you need to subscribe to Ubuntu 
Advantage for Infrastructure to get entitlement (note you need one license for 
each system you want to protect this way, so it can get Expensive).

In the Corporate IT environment (in which lethargy, inertia, extremely legacy 
software, etc. are reasons that you cannot immediately upgrade from 16.04 to 
18.04 or migrate to even newer Ubuntu), ESM allows an extra 5 years to get 
through those problems with the goal of migration or retiring of those legacy 
systems.  For the average user outside of corporations, anyone who is on 16.04 
should be migrating to newer Ubuntu, or forking out the cash per server to 
cover the ‘legacy’ software via ESM.



NOTE: I do not speak as a representative of Canonical, or the Ubuntu Security 
Team, or any other Ubuntu leadership role in this email.  The aforementioned 
information is based on my observations, information I’ve collected via my FT 
job in discussions with Canonical where we actually have UA-I subscriptions, 
and other resources and discussions with members of Canonical’s development 
teams thanks to my connections as an Ubuntu member.



Thomas


From: Ubuntu-devel-discuss  On 
Behalf Of wei tang
Sent: Wednesday, May 25, 2022 03:29
To: ubuntu-devel-discuss@lists.ubuntu.com
Cc: christoph.mar...@uni-mainz.de; k...@roeckx.be
Subject: Questions about openssl in Ubuntu mirrors

Hello, maintainers:
I am Tang Wei, a researcher in the field of open-source package management in 
Nanyang Technological University in Singapore. I am writing to you to ask some 
questions about the openssl package in Ubuntu mirrors. I would be grateful if 
you could give me some further details.

I noticed that CVE-2022-1292 affected openssl 1.1.1-1.1.1n and 1.0.2-1.0.2zd.  
It is fixed in upstream versions, OpenSSL 1.1.1o and OpenSSL 1.0.2ze. And you 
fixed it in ubuntu revisions, 1.1.1-1ubuntu2.1~18.04.17, 1.1.1f-1ubuntu2.13, 
and 1.1.1l-1ubuntu1.3.

My first question is why you modify and patch the old versions rather than 
directly updating the version to 1.1.1o. Debian maintainers seem to update to 
1.1.1o in their mirrors. 
(http://mirror.coganng.com/debian/pool/main/o/openssl/)  There is no 
compatibility issues from 1.1.1f to 1.1.1o. It seems an easier way to update it 
rather than patching it manually, isn't it?  Why not update it?

My second question is that openssl1.0.2g-1ubuntu4 in xenial is still affected 
by CVE-2022-1292. And it has been fixed in OpenSSL 1.0.2ze. Why don't you patch 
it like other ubuntu releases and leave it vulnerable. If it is caused by 
development cost, why not provide 1.0.2ze in xenial mirrors?

I look forward to hearing from you.
Thanks so much.
Tang Wei
-- 
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

required modules for package strongswan moved to linux-modules-extra-raspi

[Thomas Stegbauer]

Hi all, 

currently I had some troubles with strongswan IPsec on my raspi after upgrading 
from Ubuntu 20.04 to 22.04. 

After some investigation it came up, that required modules was moved to the 
package linux-modules-extra-raspi, unfortunatly only on arm64 / Raspberry. At 
least not on amd64, which made it harder to isolate the problem. 

Afterwards I found there is(/was) already a bug [ 
https://bugs.launchpad.net/ubuntu/+source/strongswan/+bug/1948044 | 
https://bugs.launchpad.net/ubuntu/+source/strongswan/+bug/1948044 ] which is 
marked as invalid. 

What would be best solutions to fix this issue? 

1. move back the packages to normal linux-modules? 
but I estimate there are packages not used very often on arm64 to save some 
space. 
2. create a depency on strongswan to linux-modules-extra-raspi on raspi 
platform - maybe also other plattform, but I don't know. 

br 
Thomas 
-- 
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 1977667] Re: package nginx-core 1.18.0-6ubuntu14.1 failed to install/upgrade: installed nginx-core package post-installation script subprocess returned error exit status 1

[Thomas Ward]

"failed to install/upgrade" also means that a package failed to
configure.  If as Simon says the packages were left unconfigured, then
that means the package is "Installed but failed to restart on upgrade"
which is an action the postinst scripts execute.  So it may not be an
'installer' failure but the configuration failure which led to a false
'installer failed' situation because postinst is configured to
reload/restart the NGINX processes on an upgrade.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1977667

Title:
  package nginx-core 1.18.0-6ubuntu14.1 failed to install/upgrade:
  installed nginx-core package post-installation script subprocess
  returned error exit status 1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1977667/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1977667] Re: package nginx-core 1.18.0-6ubuntu14.1 failed to install/upgrade: installed nginx-core package post-installation script subprocess returned error exit status 1

[Thomas Ward]

Looks like during your upgrade a certificate went awry, but this isn't
an NGINX issue, it's the maintenance of your system on your end.

From the journalctl data:

Jun 04 14:21:05 heliopolis-aws nginx[44002]: nginx: [emerg] cannot load 
certificate "/etc/ssl/certs/heliosd.crt": BIO_new_file() failed (SSL: 
error:8002:system library::No such file or directory:calling 
fopen(/etc/ssl/certs/heliosd.crt, r) error:1080:BIO routines::no such file)
Jun 04 14:21:05 heliopolis-aws nginx[44002]: nginx: configuration file 
/etc/nginx/nginx.conf test failed

The required certificate file is missing and can't be found.

** Changed in: nginx (Ubuntu)
   Status: New => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1977667

Title:
  package nginx-core 1.18.0-6ubuntu14.1 failed to install/upgrade:
  installed nginx-core package post-installation script subprocess
  returned error exit status 1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1977667/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1922342] Re: Impish live session takes ages to boot on BIOS systems

[Thomas Schmitt]

Hi,

i opened a separate bug with my wish for not needing a second zeroizing dd
run when the ISO is already on the USB stick:

  https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1977644
  "Please preserve MBR partition entries 2 to 4 when creating persistent 
partition"

Have a nice day :)

Thomas

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1922342

Title:
  Impish live session takes ages to boot on BIOS systems

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-release-notes/+bug/1922342/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1977644] [NEW] Please preserve MBR partition entries 2 to 4 when creating persistent partition

[Thomas Schmitt]

Public bug reported:

Hi,

i propose to let function find_or_create_persistent_partition in
scripts/casper-helpers preserve the MBR partition entries 2 to 4 when
it applies sfdisk to create the persistent partition.

Currently it writes an MBR partition entry 2 with start LBA 0, size 1,
and boot flag if it detects GPT after the persistent partition was created.
(sfdisk had overwritten it by zeros but normally the ISO shall have it.)

My idea for casper-helpers is to record the three entries in a file:

  MBR_STASH=/tmp/mbr_stash_$$
  dd if="$DEVICE" bs=1 skip=462 count=48 of="$MBR_STASH"

and to restore them after creation of the new partition

  dd if="$MBR_STASH" bs=1 seek=462 conv=notrunc count=48 of="$DEVICE"

instead of writing a newly composed entry 2, as is done now:

  echo $escape_arg -n '\0200\00\01\00\00\00\01\00\00\00\00\00\01\00\00\00' \
  | dd of=$DEVICE bs=1 seek=462 conv=notrunc count=16

---
Reasoning:

In the course of
  https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1922342
we found out that some rare old machines need 10 minutes or longer to boot
the current Ubuntu ISOs from USB stick. The trigger is the presence of the
MBR partition 2 with boot flag.

This partition exists for some old but not so rare machines. It is a
mild violation of UEFI/GPT specs which don't offer a clear way to equip
a GPT partitioned device with an MBR boot flag.

If MBR partition entry 2 of the ISO image is overwritten by zero bytes
before the image is put onto the USB stick, then it boots substantially
faster. E.g. 3 minutes rather than 10 minutes.
But casper re-installs MBR partition 2 when starting the first Live
session. So after one swift boot, the problem is back and the USB stick
needs the removal of MBR partition 2 again.
This time the remedy is permanent. But it has to be applied to the
USB stick with superuser authority.
Given that the Ubuntu tutorial proposes to put the ISO image onto the
USB stick by Balena Etcher rather than by cp or dd, i deem it not safe
to propose a dd run as superuser.

I make this change proposal so that it is possible to apply the remedy
as normal user to the ISO image file rather than as superuser to the stick.

---
Additional details:

Affected are:
- a tablet computer "motion computing j3400" of Chris Guiver,
- a Gigabyte H61M-D2H-USB3 mainboard of José Marinho (see also
  https://launchpadlibrarian.net/531427797/lshw.txt),
- (a Gigabyte GA-970A-DS3, BIOS F7a 01/24/2013 of tlk, of which we have
   no confirmation that removing MBR partition 2 really helps).

The long delay happens after the GRUB boot menu, probably still in GRUB.
I lack of ideas how to even find out whether vmlinuz hasn't started yet,
not to speak of diagnosing why it only happens with particular firmwares.

Bug 1922342 mentions an error message "Error can't find grub_platform"
which is related to a few lines grub.cfg. In the end it turned out that
disabling these lines silences the message but does not speed up booting.

Have a nice day :)

Thomas

** Affects: casper (Ubuntu)
 Importance: Undecided
 Status: New

** Description changed:

  Hi,
  
  i propose to let function find_or_create_persistent_partition in
  scripts/casper-helpers preserve the MBR partition entries 2 to 4 when
  it applies sfdisk to create the persistent partition.
  
  Currently it writes an MBR partition entry 2 with start LBA 0, size 1,
  and boot flag if it detects GPT after the persistent partition was created.
  (sfdisk had overwritten it by zeros but normally the ISO shall have it.)
  
  My idea for casper-helpers is to record the three entries in a file:
  
MBR_STASH=/tmp/mbr_stash_$$
dd if="$DEVICE" bs=1 skip=462 count=48 of="$MBR_STASH"
  
  and to restore them after creation of the new partition
  
-   dd if="$MBR_STASH" bs=1 seek=462 conv=notrunc count=48
+   dd if="$MBR_STASH" bs=1 seek=462 conv=notrunc count=48 of="$DEVICE"
  
  instead of writing a newly composed entry 2, as is done now:
  
echo $escape_arg -n '\0200\00\01\00\00\00\01\00\00\00\00\00\01\00\00\00' \
| dd of=$DEVICE bs=1 seek=462 conv=notrunc count=16
  
  ---
  Reasoning:
  
  In the course of
https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1922342
  we found out that some rare old machines need 10 minutes or longer to boot
  the current Ubuntu ISOs from USB stick. The trigger is the presence of the
  MBR partition 2 with boot flag.
  
  This partition exists for some old but not so rare machines. It is a
  mild violation of UEFI/GPT specs which don't offer a clear way to equip
  a GPT partitioned device with an MBR boot flag.
  
  If MBR partition entry 2 of the ISO image is overwritten by zero b

[Bug 1968076] Re: [BPO] ipmctl with support for CPS hardware

[Thomas Ward]

NACK as is. (negative acknowledgement aka "Debdiff Rejected")

You are attempting to submit a new upstream version not in the Ubuntu
repositories.  Unlike Debian, an Ubuntu backport requires a little more
work to push this in.

Jammy has 03.00.00.0423-1.  Your debdiff is for 03.00.00.0429 which is
**not** available in any Ubuntu release (even the development release).

Rebase your diff against the package in Jammy (dsc link:
https://launchpad.net/ubuntu/+archive/primary/+sourcefiles/ipmctl/03.00.00.0423-1/ipmctl_03.00.00.0423-1.dsc
- dget this), and then re-provide your debdiff here.  I'll check it for
sanity before uploading.

-- 
You received this bug notification because you are a member of Ubuntu
Backporters, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1968076

Title:
  [BPO] ipmctl with support for CPS hardware

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ipmctl/+bug/1968076/+subscriptions


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

[Bug 1968076] Re: [BPO] ipmctl with support for CPS hardware

[Thomas Ward]

NACK as is. (negative acknowledgement aka "Debdiff Rejected")

You are attempting to submit a new upstream version not in the Ubuntu
repositories.  Unlike Debian, an Ubuntu backport requires a little more
work to push this in.

Jammy has 03.00.00.0423-1.  Your debdiff is for 03.00.00.0429 which is
**not** available in any Ubuntu release (even the development release).

Rebase your diff against the package in Jammy (dsc link:
https://launchpad.net/ubuntu/+archive/primary/+sourcefiles/ipmctl/03.00.00.0423-1/ipmctl_03.00.00.0423-1.dsc
- dget this), and then re-provide your debdiff here.  I'll check it for
sanity before uploading.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1968076

Title:
  [BPO] ipmctl with support for CPS hardware

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ipmctl/+bug/1968076/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1968076] Re: [BPO] ipmctl with support for CPS hardware

[Thomas Ward]

If you can give me an extra day or two (I'm suffering from COVID right
now), I can sponsor this.  I'll let the other backporters handle
approval, etc. but uploading the package is something that only takes a
few minutes on my part.  (Just need the patience - COVID is evil)

-- 
You received this bug notification because you are a member of Ubuntu
Backporters, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1968076

Title:
  [BPO] ipmctl with support for CPS hardware

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ipmctl/+bug/1968076/+subscriptions


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

[Bug 1968076] Re: [BPO] ipmctl with support for CPS hardware

[Thomas Ward]

If you can give me an extra day or two (I'm suffering from COVID right
now), I can sponsor this.  I'll let the other backporters handle
approval, etc. but uploading the package is something that only takes a
few minutes on my part.  (Just need the patience - COVID is evil)

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1968076

Title:
  [BPO] ipmctl with support for CPS hardware

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ipmctl/+bug/1968076/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1976406] [NEW] f2c-compiled program produces no output

[Thomas Kenig]

Public bug reported:

$ cat hello.f 
  print *,"Hello, world"
  end
$ f2c hello.f 
hello.f:
   MAIN:
$ cat hello.c
/* hello.f -- translated by f2c (version 20160102).
   You must link the resulting object file with libf2c:
on Microsoft Windows system, link with libf2c.lib;
on Linux or Unix systems, link with .../path/to/libf2c.a -lm
or, if you install libf2c.a in a standard place, with -lf2c -lm
-- in that order, at the end of the command line, as in
cc *.o -lf2c -lm
Source for libf2c is in /netlib/f2c/libf2c.zip, e.g.,

http://www.netlib.org/f2c/libf2c.zip
*/

#include "f2c.h"

/* Table of constant values */

static integer c__9 = 9;
static integer c__1 = 1;

/* Main program */ int MAIN__(void)
{
/* Builtin functions */
integer s_wsle(cilist *), do_lio(integer *, integer *, char *, ftnlen), 
e_wsle(void);

/* Fortran I/O blocks */
static cilist io___1 = { 0, 6, 0, 0, 0 };


s_wsle(___1);
do_lio(__9, __1, "Hello, world", (ftnlen)12);
e_wsle();
return 0;
} /* MAIN__ */

$ gcc hello.c -lf2c
$ ./a.out
$

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: f2c 20160102-1
ProcVersionSignature: Ubuntu 5.4.0-113.127-generic 5.4.181
Uname: Linux 5.4.0-113-generic x86_64
NonfreeKernelModules: nvidia_modeset nvidia
ApportVersion: 2.20.11-0ubuntu27.24
Architecture: amd64
CasperMD5CheckResult: pass
CurrentDesktop: KDE
Date: Tue May 31 22:15:02 2022
InstallationDate: Installed on 2021-03-27 (430 days ago)
InstallationMedia: Ubuntu-Server 20.04.2 LTS "Focal Fossa" - Release amd64 
(20210201.2)
SourcePackage: f2c
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: f2c (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug focal

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1976406

Title:
  f2c-compiled program produces no output

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/f2c/+bug/1976406/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1964763] Re: QtChooser doesn't support qt6

[Thomas Ward]

If Qt6 is dead upstream, then it's probably a candidate for removal as
soon as Qt5 is retired.

Note that because Debian has refused to even add Qt6 because QtChooser
is dead upstream by design, and I'm gathering as such should not be used
with Qt6, I opened a Debian bug suggesting that they mark the package as
"Breaks:" for all Qt6 libraries.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011935

** Bug watch added: Debian Bug tracker #1011935
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011935

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1964763

Title:
  QtChooser doesn't support qt6

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/qtchooser/+bug/1964763/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1973618] Re: can no longer open new windows after some time

[Thomas M Steenholdt]

I haven't been able to find other actual bugs/issues describing this
issue, but there are threads on reddit and such that seem to indicate
that this is a wayland/gnome42 issue, and that it affects all
distributions.

https://www.reddit.com/r/gnome/comments/ugpe12/firefox_on_gnome_42_cant_open_new_windows_after/
https://www.reddit.com/r/archlinux/comments/ugp9af/firefox_on_gnome_42_wayland_cant_create_new/

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1973618

Title:
  can no longer open new windows after some time

To manage notifications about this bug go to:
https://bugs.launchpad.net/firefox/+bug/1973618/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1975741] Re: linux-oem-22.04(a) does not load MOK certificates

[Thomas Boerner]

Sorry something went wrong with copy/paste in the description.

Central issue is that the part where the MOK certificates are loaded (in 
5.15.0-33-generic):
```Mai 25 00:14:56 silvershadow kernel: integrity: Loading X.509 certificate: 
UEFI:MokListRT (MOKvar table)
Mai 25 00:14:56 silvershadow kernel: integrity: Loaded X.509 cert 'Canonical 
Ltd. Master Certificate Authority: ad91990bc22ab1f517048c23b66>
Mai 25 00:14:56 silvershadow kernel: integrity: Loading X.509 certificate: 
UEFI:MokListRT (MOKvar table)
Mai 25 00:14:56 silvershadow kernel: integrity: Loaded X.509 cert 'silvershadow 
Secure Boot Module Signature key: d0f162f7b494c7188637ff51f>
```
is missing when booting 5.17.0-1006-oem.

Hope that helps

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1975741

Title:
  linux-oem-22.04(a) does not load MOK certificates

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-meta-oem-5.17/+bug/1975741/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1975741] [NEW] linux-oem-22.04(a) does not load MOK certificates

[Thomas Boerner]

Public bug reported:

I started to test the oem kernel on ubuntu 22.04 jammy. Doing so I
wondered why all my dkms modules don't load when secure boot is active
although they are correctly signed. After investigating quite a while I
found that the MOK certificates are not loaded during boot. This is from
journalctl -k with the hwe kernel (currently 5.15.0-33-generic) where
everything is fine:

```
Mai 25 00:14:56 silvershadow kernel: Loading compiled-in X.509 certificates
Mai 25 00:14:56 silvershadow kernel: Loaded X.509 cert 'Build time 
autogenerated kernel key: cee583cd7127fcb5e727bd8fee80ccf9b6c19422'
Mai 25 00:14:56 silvershadow kernel: Loaded X.509 cert 'Canonical Ltd. Live 
Patch Signing: 14df34d1a87cf37625abec039ef2bf521249b969'
Mai 25 00:14:56 silvershadow kernel: Loaded X.509 cert 'Canonical Ltd. Kernel 
Module Signing: 88f752e560a1e0737e31163a466ad7b70a850c19'
Mai 25 00:14:56 silvershadow kernel: blacklist: Loading compiled-in revocation 
X.509 certificates
Mai 25 00:14:56 silvershadow kernel: Loaded X.509 cert 'Canonical Ltd. Secure 
Boot Signing: 61482aa2830d0ab2ad5af10b7250da9033ddcef0'
Mai 25 00:14:56 silvershadow kernel: zswap: loaded using pool lzo/zbud
Mai 25 00:14:56 silvershadow kernel: Key type ._fscrypt registered
Mai 25 00:14:56 silvershadow kernel: Key type .fscrypt registered
Mai 25 00:14:56 silvershadow kernel: Key type fscrypt-provisioning registered
Mai 25 00:14:56 silvershadow kernel: Key type trusted registered
Mai 25 00:14:56 silvershadow kernel: Key type encrypted registered
Mai 25 00:14:56 silvershadow kernel: AppArmor: AppArmor sha1 policy hashing 
enabled
Mai 25 00:14:56 silvershadow kernel: integrity: Loading X.509 certificate: 
UEFI:db
Mai 25 00:14:56 silvershadow kernel: integrity: Loaded X.509 cert 'Dell Inc.: 
Dell Bios DB Key: 637fa7a9f74471b406de0511557071fd41dd5487'
Mai 25 00:14:56 silvershadow kernel: integrity: Loading X.509 certificate: 
UEFI:db
Mai 25 00:14:56 silvershadow kernel: integrity: Loaded X.509 cert 'Dell Inc.: 
Dell Bios FW Aux Authority 2018: dd4df7c3f5ce7e5a77847915abc3>
Mai 25 00:14:56 silvershadow kernel: integrity: Loading X.509 certificate: 
UEFI:db
Mai 25 00:14:56 silvershadow kernel: integrity: Loaded X.509 cert 'Microsoft 
Windows Production PCA 2011: a92902398e16c49778cd90f99e4f9ae17>
Mai 25 00:14:56 silvershadow kernel: integrity: Loading X.509 certificate: 
UEFI:db
Mai 25 00:14:56 silvershadow kernel: integrity: Loaded X.509 cert 'Microsoft 
Corporation UEFI CA 2011: 13adbf4309bd82709c8cd54f316ed522988a>
Mai 25 00:14:56 silvershadow kernel: integrity: Revoking X.509 certificate: 
UEFI:dbx
Mai 25 00:14:56 silvershadow kernel: blacklist: Revoked X.509 cert 'Microsoft 
Windows PCA 2010: d14fa98a0708cef4241898e500fff3d6791d37bc'
Mai 25 00:14:56 silvershadow kernel: integrity: Loading X.509 certificate: 
UEFI:MokListRT (MOKvar table)
Mai 25 00:14:56 silvershadow kernel: integrity: Loaded X.509 cert 'Canonical 
Ltd. Master Certificate Authority: ad91990bc22ab1f517048c23b66>
Mai 25 00:14:56 silvershadow kernel: integrity: Loading X.509 certificate: 
UEFI:MokListRT (MOKvar table)
Mai 25 00:14:56 silvershadow kernel: integrity: Loaded X.509 cert 'silvershadow 
Secure Boot Module Signature key: d0f162f7b494c7188637ff51f>
Mai 25 00:14:56 silvershadow kernel: Loading compiled-in module X.509 
certificates
Mai 25 00:14:56 silvershadow kernel: Loaded X.509 cert 'Build time 
autogenerated kernel key: cee583cd7127fcb5e727bd8fee80ccf9b6c19422'
Mai 25 00:14:56 silvershadow kernel: ima: Allocated hash algorithm: sha1
Mai 25 00:14:56 silvershadow kernel: ima: No architecture policies found
```

And this is from journalctl -k with the oem kernel (currently
5.17.0-1006-oem) where the MOK certificates are not loaded:

```
Mai 24 23:53:20 silvershadow kernel: Loading compiled-in X.509 certificates
Mai 24 23:53:20 silvershadow kernel: Loaded X.509 cert 'Build time 
autogenerated kernel key: f588ef5f31df3af9af115966e412ed048604418c'
Mai 24 23:53:20 silvershadow kernel: Loaded X.509 cert 'Canonical Ltd. Live 
Patch Signing: 14df34d1a87cf37625abec039ef2bf521249b969'
Mai 24 23:53:20 silvershadow kernel: Loaded X.509 cert 'Canonical Ltd. Kernel 
Module Signing: 88f752e560a1e0737e31163a466ad7b70a850c19'
Mai 24 23:53:20 silvershadow kernel: blacklist: Loading compiled-in revocation 
X.509 certificates
Mai 24 23:53:20 silvershadow kernel: Loaded X.509 cert 'Canonical Ltd. Secure 
Boot Signing: 61482aa2830d0ab2ad5af10b7250da9033ddcef0'
Mai 24 23:53:20 silvershadow kernel: zswap: loaded using pool lzo/zbud
Mai 24 23:53:20 silvershadow kernel: Key type ._fscrypt registered
Mai 24 23:53:20 silvershadow kernel: Key type .fscrypt registered
Mai 24 23:53:20 silvershadow kernel: Key type fscrypt-provisioning registered
Mai 24 23:53:20 silvershadow kernel: Key type trusted registered
Mai 24 23:53:20 silvershadow kernel: Key type encrypted registered
Mai 24 23:53:20 silvershadow kernel: AppArmor: AppArmor sha1 policy hashing 
enabled
Mai 24 23:53:20 silvershadow kernel: 

[Bug 1975421] Re: Make Plymouth hide ALL messages on boot, reboot, halt. Plymouth ignores --no-boot-log flag

[Thomas Weissel]

*** This bug is a duplicate of bug 1970069 ***
https://bugs.launchpad.net/bugs/1970069

well i'm getting to the roots of this step by step.. but as far as i see
it now i reported a bug where kernel parameters that set the loglevel
are beeing ignored by system daemons that monitor the init process.

the other bug is about plymouth not hiding these messages.

so the headline of this bug should be corrected.. or.. i'll do another report 
that pinpoints the problem better
because it's probaly not even a plymouth problem ?

** Description changed:

- running a fresh install of kubuntu 22.04 
+ running a fresh install of kubuntu 22.04
  plymouth version: 0.9.5+git20211018-1ubuntu3
  
+ What should happen:
+ no bootmessages should be printed to console in the first place
  
- What should happen:  
- Plymouth should totally cover all bootmessages (no bootmessages should be 
printed to console in the first place)
+ What actually happens:
+ When Plymouth quits the last 2-3 messages are visible - so some boot messages 
are printed to console never the less
  
- What actually happens: 
- When Plymouth quits the last 2-3 messages are visible
- 
- on shutdown i get:
+ on shutdown for example i get:
  [OK] Reached target Late Shutdown Services
  [OK] Finished System Power Off
  [OK] Reached target System Power off
  
- 
- it seems to be absolutely impossible to hide all boot messages 
+ it seems to be absolutely impossible to hide all boot messages
  i've done everything from this arch wiki site (and more) to get a silent 
boot: https://wiki.archlinux.org/title/silent_boot
  (this makes all acpi warnings and more go away.. but the [OK] 
reached/finished messages are not affected by those kernel parameters (this 
should also be fixed)
  
- My Kernelparameters: 
- fbcon=nodefer rd.systemd.show_status=false vt.global_cursor_default=0 quiet 
splash loglevel=3 rd.udev.log_level=3
+ My Kernelparameters:quiet splash fbcon=nodefer rd.systemd.show_status=0
+ systemd.show_status=0 vt.global_cursor_default=0 loglevel=0
+ rd.udev.log_level=0 udev.log_level=0 rd.systemd.log_level=0
+ systemd.log_level=0
  
- 
- What part of the system throws these messages ? i thought it is systemd? 
+ What part of the system throws these messages ? 
+ i thought it is systemd?
  so i even edited files in /usr/lib/systemd/system in order to set the 
StandardOutput to null for all of the halt and reboot and plymouth scripts
  
  and i edited the plymouth start and stop scripts and added -no-boot-log
  but plymouth totally ignores this flag and still logs everything to
  console and to /var/log/boot.log
  
- 
- this defies the whole purpose of plymouth if plymouth itself spams the 
console with messages and if it's systemd why doesn't it respect the kernel 
parameters
+ this defies the whole purpose of plymouth if plymouth itself spams the
+ console with messages and if it's systemd why doesn't it respect the
+ kernel parameters

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1975421

Title:
  Make Plymouth hide ALL messages on boot, reboot, halt. Plymouth
  ignores --no-boot-log flag

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1975421/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1975421] Re: Make Plymouth hide ALL messages on boot, reboot, halt. Plymouth ignores --no-boot-log flag

[Thomas Weissel]

*** This bug is a duplicate of bug 1970069 ***
https://bugs.launchpad.net/bugs/1970069

i'm quite sure that this is NOT a duplicate.. the other bug refers to
some kernel upgrades that lead to error messages with acpi and usb
devices in 22.04 (i also have these kernel messages but they are easily
hidden with the kernel boot parameters i've mentioned above - especially
loglevel=0)

my bugreport says that even with all of these kernel parameters in place i 
still have the 
[OK] Finished ServiceXY 
messages.

so they are related (because if plymouth would do it's job it wouldn't
matter that those boot parameters are ignored) but they actually target
two different problems

also i believe that these messages (the ones i am talking about) aren't kernel 
messages but systemd or plymouth logs
they are written to boot.log

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1975421

Title:
  Make Plymouth hide ALL messages on boot, reboot, halt. Plymouth
  ignores --no-boot-log flag

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1975421/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1975421] [NEW] Make Plymouth hide ALL messages on boot, reboot, halt. Plymouth ignores --no-boot-log flag

[Thomas Weissel]

Public bug reported:

running a fresh install of kubuntu 22.04 
plymouth version: 0.9.5+git20211018-1ubuntu3


What should happen:  
Plymouth should totally cover all bootmessages (no bootmessages should be 
printed to console in the first place)

What actually happens: 
When Plymouth quits the last 2-3 messages are visible

on shutdown i get:
[OK] Reached target Late Shutdown Services
[OK] Finished System Power Off
[OK] Reached target System Power off


it seems to be absolutely impossible to hide all boot messages 
i've done everything from this arch wiki site (and more) to get a silent boot: 
https://wiki.archlinux.org/title/silent_boot
(this makes all acpi warnings and more go away.. but the [OK] reached/finished 
messages are not affected by those kernel parameters (this should also be fixed)

My Kernelparameters: 
fbcon=nodefer rd.systemd.show_status=false vt.global_cursor_default=0 quiet 
splash loglevel=3 rd.udev.log_level=3


What part of the system throws these messages ? i thought it is systemd? 
so i even edited files in /usr/lib/systemd/system in order to set the 
StandardOutput to null for all of the halt and reboot and plymouth scripts

and i edited the plymouth start and stop scripts and added -no-boot-log
but plymouth totally ignores this flag and still logs everything to
console and to /var/log/boot.log


this defies the whole purpose of plymouth if plymouth itself spams the console 
with messages and if it's systemd why doesn't it respect the kernel parameters

** Affects: plymouth (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1975421

Title:
  Make Plymouth hide ALL messages on boot, reboot, halt. Plymouth
  ignores --no-boot-log flag

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1975421/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1922342] Re: Impish live session takes ages to boot on BIOS systems

[Thomas Schmitt]

Hi,

tlk wrote:
> which post details the "removing MBR partition 2"?

#112 by me, confirmed by #114 by Chris Guiver:

If the USB stick with the the slowly booting ISO is overwritten
meanwhile:

  # Patch the ISO already as image on hard disk
  ISO=ubuntu-22.04-desktop-amd64.iso
  dd if=/dev/zero bs=1 count=16 of="$ISO" conv=notrunc seek=462

  # Put it onto the USB stick as you usually do. E.g.
  sudo dd bs=4M oflag=sync status=progress of=/dev/sdX if="$ISO"

In any case after the USB stick has already booted once, you have to apply
the change again directly to it, because casper installed MBR partition 2
again after creating its persistent partition:

  # Take care not to name any of your valuable disks as USB_STICK
  USB_STICK=/dev/sdX
  sudo dd if=/dev/zero bs=1 count=16 of="$USB_STICK" conv=notrunc seek=462

Have a nice day :)

Thomas

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1922342

Title:
  Impish live session takes ages to boot on BIOS systems

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-release-notes/+bug/1922342/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1975388] Re: upgrade from 18.04 to 20.04 while on rollbacked kernel 4.15-0-177 - package grub-efi-amd64-signed 1.167.2+2.04-1ubuntu44.2 failed to install/upgrade: installed grub-efi-amd64-signed

[Bijo Alex Thomas]

Agree with the comment and this particular update process is likely
acting as expected since an unsigned kernel was found. However, just to
set the context right - I didn't install the unsigned kernel. I rolled
back kernel 4.15-0-177 to work around Bug #1973482, using apt remove and
it automatically installed the unsigned version instead.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1975388

Title:
  upgrade from 18.04 to 20.04 while on rollbacked kernel 4.15-0-177 -
  package grub-efi-amd64-signed 1.167.2+2.04-1ubuntu44.2 failed to
  install/upgrade: installed grub-efi-amd64-signed package post-
  installation script subprocess returned error exit status 1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub2-signed/+bug/1975388/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1975388] [NEW] upgrade from 18.04 to 20.04 while on rollbacked kernel 4.15-0-177 - package grub-efi-amd64-signed 1.167.2+2.04-1ubuntu44.2 failed to install/upgrade: installed grub-efi-amd64-signe

[Bijo Alex Thomas]

Public bug reported:

Dell XPS 15 9570. Dual boot with Windows 10. Linux was on 18.04 when
attempting to upgrade to 20.04. Had previously installed kernel
4.15-0-177 which was rolled back to working kernel 4.15-0-175 due to
issues already reported in Bug #1973482. Due to rollback, there was an
unsigned image of kernel 4.15-0-177 in the machine, which caused the
upgrade 20.04 to fail with following error. Ubuntu upgrade attempted
while logged into kernel 4.15-0-175.

package grub-efi-amd64-signed 1.167.2+2.04-1ubuntu44.2 failed to
install/upgrade: installed grub-efi-amd64-signed package post-
installation script subprocess returned error exit status 1

ProblemType: Package
DistroRelease: Ubuntu 20.04
Package: grub-efi-amd64-signed 1.167.2+2.04-1ubuntu44.2
ProcVersionSignature: Ubuntu 5.4.0-110.124-generic 5.4.181
Uname: Linux 5.4.0-110-generic x86_64
NonfreeKernelModules: nvidia_modeset nvidia
ApportVersion: 2.20.11-0ubuntu27.24
Architecture: amd64
CasperMD5CheckResult: skip
Date: Sat May 21 12:24:34 2022
ErrorMessage: installed grub-efi-amd64-signed package post-installation script 
subprocess returned error exit status 1
InstallationDate: Installed on 2018-09-23 (1336 days ago)
InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 (20180725)
Python3Details: /usr/bin/python3.8, Python 3.8.10, python3-minimal, 
3.8.2-0ubuntu2
PythonDetails: /usr/bin/python2.7, Python 2.7.18, python-is-python2, 2.7.17-4
RelatedPackageVersions:
 dpkg 1.19.7ubuntu3
 apt  2.0.8
SourcePackage: grub2-signed
Title: package grub-efi-amd64-signed 1.167.2+2.04-1ubuntu44.2 failed to 
install/upgrade: installed grub-efi-amd64-signed package post-installation 
script subprocess returned error exit status 1
UpgradeStatus: Upgraded to focal on 2022-05-21 (0 days ago)

** Affects: grub2-signed (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-package focal need-duplicate-check

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1975388

Title:
  upgrade from 18.04 to 20.04 while on rollbacked kernel 4.15-0-177 -
  package grub-efi-amd64-signed 1.167.2+2.04-1ubuntu44.2 failed to
  install/upgrade: installed grub-efi-amd64-signed package post-
  installation script subprocess returned error exit status 1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub2-signed/+bug/1975388/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1922342] Re: Impish live session takes ages to boot on BIOS systems

[Thomas Schmitt]

Hi,

Chris Guiver wrote:
> This confirms what I believe you wanted.

Yes.
The stick needs the remedy once again after casper created the persistent
partition.

sudodus wrote:
> This is like development of physics ;-)

Like a unification of relativity theory and quantum mechanics ?

My apologies again for not remembering the results from one year ago
and wasting everybody's time with my first questions of this year.
Between #94 and #103 i was off track.

I'll wait a few days whether Steve Langasek shows up at this bug report.
If not, i plan to file a new wishlist bug for casper which describes
our findings and proposes the code change as of #115.

I re-re-read this report to list the affected machines:
- a tablet computer "motion computing j3400" of Chris Guiver,
- a Gigabyte H61M-D2H-USB3 mainboard of José Marinho (see also
  https://launchpadlibrarian.net/531427797/lshw.txt),
- (a Gigabyte GA-970A-DS3, BIOS F7a 01/24/2013 of tlk in #91, of which we
   have no confirmation that removing MBR partition 2 really helps).

Have a nice day :)

Thomas

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1922342

Title:
  Impish live session takes ages to boot on BIOS systems

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-release-notes/+bug/1922342/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1922342] Re: Impish live session takes ages to boot on BIOS systems

[Thomas Schmitt]

Hi,

Chris Guiver wrote:
> On j3400; pressed ENTER (at grub) at 13:10 (room clock)..  I didn't note
> time of plymouth but I had maybe-ubiquity @ 13:13 (room clock) for
> altered version of 2022-04-19 ISO
> [...]
> so I'll now boot twice
> [...]
> alas should have noted clock.. it 'feels' slow... nah it's slow :(
> [...]
> another boot on j3400, hit ENTER (at grub) at 13:31, maybe-ubiquity jingle
> waking me from sleep at 13:41
> [...]
> MBR partition  :   2   0x80  0x0001

Looks like casper is still re-installing MBR partition 2 on the first
run of the Live system, although it was not there before this run.

If you now apply the remedy to the stick
  dd if=/dev/zero bs=1 count=16 of=/dev/sdb conv=notrunc seek=462
then i expect it to be permanently booting in reasonable time.
(Not because it was applied to the stick, but because casper will not
manipulate the partition table any more.)

Please confirm.

--

I had hoped that capser would save the partition entry and re-install it after
the creation of the persistent overwrote the MBR partition table. But it
seems to just write a pre-recorded partition entry with the boot flag.

So we'd need a change in casper if the description of the workaround
shall be reasonably safe.
I don't consider dd of=/dev/sdb safe considered that the Ubuntu tutorial
advises to use Balena Etcher for the copy-to-USB-stick step.

Casper would have to save before the additon of the persisten partition
at least 16 bytes beginning at offset 462, or 48 bytes to cover all three
unused MBR partitions. After creation of the partition the saved bytes
would be written back to the MBR of the USB stick.

In
  https://bugs.launchpad.net/ubuntu-cdimage/+bug/1899308/comments/66
i read:

   casper (1.455) groovy; urgency=medium
 [...]
 * Limit our dd to only change 16 bytes in the MBR regardless of input,
 [...]
   -- Steve Langasek  Fri, 16 Oct 2020 09:51:20 -0700

But this is not what Chris Guiver observes.

In
  
https://git.launchpad.net/ubuntu/+source/casper/commit/?id=5c3637a224e7eca4c8998d72ac1711cd8b58b335
i see unconditional insertion of the boot flag partition:

  +  echo $escape_arg -n '\0200\00\01\00\00\00\01\00\00\00\00\00\01\00\00\00' \
  +  | dd of=$DEVICE bs=1 seek=462 conv=notrunc count=16

The current state in
  https://git.launchpad.net/ubuntu/+source/casper/tree/scripts/casper-helpers
still has this gesture:

  find_or_create_persistent_partition () {
  [...]
  echo "start=$start" | sfdisk --no-reread -q $DEVICE -a || return
  [...]
  if sfdisk -d $DEVICE | grep -q 'label: gpt'; then
  [...]
  echo $escape_arg -n 
'\0200\00\01\00\00\00\01\00\00\00\00\00\01\00\00\00' \
  | dd of=$DEVICE bs=1 seek=462 conv=notrunc count=16
  fi
  [...]

I would propose to do something like:

 +MBR_STASH=/tmp/mbr_stash_$$
 +dd if="$DEVICE" bs=1 skip=462 count=48 of="$MBR_STASH"
  echo "start=$start" | sfdisk --no-reread -q $DEVICE -a || return
  [...]
 -echo $escape_arg -n 
'\0200\00\01\00\00\00\01\00\00\00\00\00\01\00\00\00' \
 -| dd of=$DEVICE bs=1 seek=462 conv=notrunc count=16
 +dd if="$MBR_STASH" bs=1 seek=462 conv=notrunc count=48
  fi
 +rm "$MBR_STASH"

@Steve Langasek: Are you watching ? Do we need to open a new bug ?

Have a nice day :)

Thomas

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1922342

Title:
  Impish live session takes ages to boot on BIOS systems

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-release-notes/+bug/1922342/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1922342] Re: Impish live session takes ages to boot on BIOS systems

[Thomas Schmitt]

Hi,

i wrote towards Chris Guiver:
> it would
> be a good base if you could confirm that j3400 boots after the plain
> procedure with no other experiments inbetween

I should have written:

  it would be a good base if you could confirm that j3400 boots without
  the extra delay of ~6 minutes after the plain procedure with no other
  experiments inbetween

Reading my text proposal for the tutorial, i now think it should give
less info. Like

  On some very old and meanwhile rare machines it can last 10 minutes or
  longer until you see this welcome screen.
  If you really have to wait that long, consider to read the article [link]
  about a possible cause and a workaround.

The article would explain that
- the Ubuntu ISOs contain a boot flag as inavoidable workaround for booting
  some old and not so rare machines,
- which causes the long boot delay with some other old and rarer machines,
- and can be disabled by the dd procedure.

Have a nice day :)

Thomas

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1922342

Title:
  Impish live session takes ages to boot on BIOS systems

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-release-notes/+bug/1922342/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1922342] Re: Impish live session takes ages to boot on BIOS systems

[Thomas Schmitt]

Hi,

Chris Guiver wrote:
> libburn : SORRY : Failed to open device (a pseudo-drive) : Permission denied

Oops. No read permission for normal users on USB sticks.
(I should really operate my workstation with a more conventional setup
so that i better anticipate other's adventures.)

> My thumb-drive K does not boot on
> - hp dc7700 (c2d-e6320, 5gb, nvidia quadro nvs 290)
> - hp dc7900 (c2d-e8400, 4gb, intel 4 series integrated i915)
> as it stands now.

Obviously the addicted HPs don't see a boot flag.

>  echo $'\x80' | dd of=/dev/sdb bs=1 count=1 conv=notrunc seek=446
> it NOW BOOTS ON
> - hp dc7700 (c2d-e6320, 5gb, nvidia quadro nvs 290)
> - hp dc7900 (c2d-e8400, 4gb, intel 4 series integrated i915)

Another confirmation that the flag was not set before.

The only small chance for a red herring would be a prolonged history of
experiments with the ISO on the stick, which would have caused casper to
not do what it normally does. We had that in the #50s comments.

--

So if we want to propose a workaround for the current layout, it would
be a good base if you could confirm that j3400 boots after the plain
procedure with no other experiments inbetween:

  # Patch the ISO already as image on hard disk
  ISO=ubuntu-22.04-desktop-amd64.iso
  dd if=/dev/zero bs=1 count=16 of="$ISO" conv=notrunc seek=462

  # Put it onto the USB stick as you usually do. E.g.
  sudo dd bs=4M oflag=sync status=progress of=/dev/sdb if="$ISO"

Then you would check if it boots twice on the j3400. If the second boot
succeeds and shows a writable big partition as last one, then we could be
sure that this procedure is a valid workaround.

A run of

  sudo xorriso -indev stdio:/dev/sdb -report_system_area plain

would (hopefully) confirm that there is no second MBR partition with boot
flag.

Of course it would be enough if you can confirm that you did this already
during the experiments, with no intermediate manipulations.
But given the curvy way of this bug report, we need to be sure.

--

Assumed that

  dd if=/dev/zero bs=1 count=16 of="$ISO" conv=notrunc seek=462

is really a reliable way to make the Ubuntu ISOs boot on the few old
BIOS machines, which slow down GRUB when encountering the combination of
GPT and MBR dummy partition, we would need a way to inform the downloaders
of Ubuntu ISOs about this trick.

To whom would we have to talk to get this proposal onto sites like
  https://ubuntu.com/tutorials/install-ubuntu-desktop
which gets pointed to by a link on
  https://ubuntu.com/download/desktop

I think it should be mentioned in
  
https://ubuntu.com/tutorials/install-ubuntu-desktop#4-boot-from-usb-flash-drive
like
  "On some very old and meanwhile rare machines it can last 8 minutes or
   longer until you see this welcome screen.
   If you plan just a single installation then simply wait until the screen
   appears.
   But if you plan to repeatedly use the "Try Ubuntu" offer on such an old
   machine, then see [link to new page tutorials/remove-boot-flag-from-iso]
   for a way to substantially shorten this time span."

The new page would briefly explain the problem and propose the manipulation
before putting the ISO onto the USB stick.
It would warn not to do this unless a first boot attempt really lasted
unreasonably long.

Have a nice day :)

Thomas

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1922342

Title:
  Impish live session takes ages to boot on BIOS systems

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-release-notes/+bug/1922342/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1922342] Re: Impish live session takes ages to boot on BIOS systems

[Thomas Schmitt]

Hi,

Chris Guiver wrote:
> └─sdb4   8:20   1 4G  0 part /media/guiverc/writable

So it seems that casper added its persistent partition without creating
a dummy MBR partition with boot flag.
This simplifies the task of making current Ununtu ISOs digestible for
the j3400. One run of

  dd if=/dev/zero bs=1 count=16 of="$STICK" conv=notrunc seek=462

suffices.


Chris Guiver wrote:
> guiverc@d960-ubu2:~/uwn/issues/735$   xorriso -indev /dev/sdb 
> -report_system_area plain
> xorriso : FAILURE : Drive address '/dev/sdb' rejected because: not MMC and 
> -drive_class 'caution' '/dev'

My mistake. The program is right. The command proposal should have been

  xorriso -indev stdio:/dev/sdb -report_system_area plain

Please run this to verify that the dummy partition is really not there
after the first successful booting of the USB stick.

(The demand for the "stdio:" prefix is a safety precaution to protect
system disks from dangerous superuser activities.
I forgot about it because i have a file /etc/opt/xorriso/rc which declares
  -drive_class harmless '/dev/sd[c-e]*'
so that i don't have to use "stdio:" with my USB sticks.
Whatever, -indev without -outdev to the same device prevents writing
and -report_system_area "plain" does not want to write to the device.
So it would be safe even for the system disks.)

Have a nice day :)

Thomas

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1922342

Title:
  Impish live session takes ages to boot on BIOS systems

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-release-notes/+bug/1922342/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1922342] Re: Impish live session takes ages to boot on BIOS systems

[Thomas Schmitt]

Hi,

Chris Guiver wrote:
> I performed the command
> `sudo dd if=/dev/zero bs=1 count=16 of=/dev/sdb conv=notrunc seek=462`
> to Ubuntu Desktop 22.04 LTS thumb-drive (K)
> Booted on j3400
> BOOT1: 
> it was fully-operational at 2 min 45 secs

So it looks like the dd run brought about the best boot-up speed we can
expect from this hardware. (Please contradict me if i'm wrong.)


> system just rebooted  (alt-sysreq+reisub)
> 03:11  system fully-operational

So casper did not re-install the dummy partition 2 when creating a persistent
partition.

Well, did it create a new partition at all ?
What do you get from

  xorriso -indev /dev/sdb -report_system_area plain

Expectation:
The report about the MBR partition table should list only one partition

  MBR partition table:   N Status  TypeStart   Blocks
  MBR partition  :   1   0x00  0xee1  5090363

with possibly the Blocks number adjusted to the size of your USB stick.
(The original ISO would show a MBR partition 2
  MBR partition  :   2   0x80  0x0001
which obviously makes the trouble with j3400.)

The GPT part of the report would list a fourth GPT partition, if casper
created one.


> BUT FAILED TO BOOT on
> - hp dc7700 (c2d-e6320, 5gb, nvidia quadro nvs 290)

This is obviously one of the machines which demand a boot flag in MBR.

Does it boot after you (rawly and naughtily) set the boot flag to MBR
partition 1:

  echo $'\x80' | dd of=/dev/sdX bs=1 count=1 conv=notrunc seek=446

(If Ubuntu decides to leave these machines behind, this run could be the
remedy for hp dc7700 and others. It is simpler than a dd run which installs
partition 2. On the other hand it is clearly violating the specs.)

What does the j3400 do with this state of the USB stick ?

(If it boots slowly:
Above dd run can be revoked by "cat /dev/zero" instead of "echo $'\x80'".)

---

It looks like a fundamental decision by Ubuntu is needed:

Since GPT specs forbid the boot flag with the MBR partition of type 0xee
and since some EFI implementations indeed take offense if it is there,
the MBR partition with its boot flag was the best compromise ... until
j3400 and José Marinho's machine of which i could not find a model name.

But now seems that Ubuntu needs to decide with its ISOs whether to leave
behind either j3400 or hp dc7700.
A good reason for keeping j3400 bootable is that this partition layout is
fully specs compliant and tasty to all EFI implementations (... so far).

The only partition layout for hp dc7700 which complies to UEFI and its GPT
specs would be a MBR partition table marking the EFI partition by type 0xEF
and no GPT.
But although this is covered by the specs, there are EFI implementations
known which don't boot from a device without GPT.

(Really annoying to me is the fact that the old ISOLINUX/GRUB jackalope works
for all machines with its MBR partition table and a dead GPT strapped on its
back. Somehow i hope for a widely used EFI which hates it and forces it
out of the world.)

I guess that it is not an option to provide full ISO sets for both, the
mainstream and some old exotic firmwares. I hope that the old jackalope is
not an option either.

So we should find easy-to-apply remedies for those old machines which need
to be left behind. To do so, we need to know which group of them will be
abandoned by the unmodified ISOs.


Have a nice day :)

Thomas

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1922342

Title:
  Impish live session takes ages to boot on BIOS systems

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-release-notes/+bug/1922342/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Re: isc-dhcp: should we start phasing it out?

[Thomas Ward]

Mark,

I'm tempted to start the migration to Kea, but the documentation is 
extremely vague on proper migration.  If we intend to move in that 
direction, we'll need to have a migration guide of some sort, so that 
it's a more seamless transition for people.  Just a thought.



Thomas



On 5/16/22 14:40, Mark Shuttleworth wrote:

On 16/05/2022 18:34, Andreas Hasenack wrote:

Could we perhaps start with phasing out the client, get its rdeps to
use alternatives, and then stop building it, and eventually get to the
server? This could be a lot of work, as I said, isc-dhcp is a classic,
but if upstream is shifting its focus elsewhere, soon we will be
alone.



Thanks for raising the topic. Upstream is clearly signalling their 
preference for a Kea-only future, so one way or another folks who are 
on ISC dhcpd are going to need to pick a new offering. I moved a 
network to Kea last year because ISC dhcpd HA had a number of 
unexpected behaviours, Kea seems much more rational in that regard and 
a good fit for our own offerings and services such as MAAS. I also 
think we might be able to contribute dqlite support for Kea upstream, 
which would make HA even easier.


Mark






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

Re: Legality of using free VMware Workstation Player for alpha and beta testing of Ubuntu?

[Thomas Ward]

If you are in doubt for any reason, this is where you need to work with 
a lawyer in your own jurisdiction to determine the legality.


None of us are lawyers, so any advice we give should be taken with a 
grain of salt.  I don't think VMware will come after you though for 
using it to test Ubuntu or Lubuntu.



Thomas
(sent without my @ubuntu.com because GMail addresses are involved)

On 5/14/22 21:42, Aaron Rainbolt wrote:
Thank you for taking the time to reply. This is sort of what I was 
thinking when I asked the question, but it's still close enough to a 
problem that I'm worried about it. In addition, I intend on using 
Ubuntu for commercial use in the not-too-distant future, so I'd rather 
not risk getting myself on the bad side of a multi-billion dollar 
company. For now, I have virt-manager, I can get Virtualbox (the 
open-source version, not with the proprietary add-on pack), I've got 
some good physical hardware, and you guys have VMware licenses for 
testing that part of things, so I think I'll just use what I've got 
for the time being, and possibly buy a VMware license at some point in 
the future.


On Sat, May 14, 2022 at 11:21 AM John Chittum 
 wrote:


Not a lawyer, so grain of salt.

Ubuntu, the OS, is not a commercial product by itself. Ubuntu is
offered as a free and open source OS. If you are testing
non-commercial offerings of Ubuntu, as part of community work,
then it should be fine to use VMWare Player, Virtualbox, or other
items for non-commercial work. Community work is, by definition,
not commercial.

If you are working on a commercial product, for instance, testing
Ubuntu Pro features offered by Canonical, or an appliance that
will be sold to a customer, then you may be in violation. If you
are an employee of Canonical employed to work on the OS, things
get dicey _but_ there are options available (we have licenses
available). Or if you are using it as part of your job (say,
you're a sys admin, and part of your job is to vet Ubuntu, and you
just happen to also contribute upstream when you find a bug). Then
you should talk to your workplace about getting you a license.

TL:DR if it's solely community work, it shouldn't be a breach.
Other things would be case by case.


On Sat, May 14, 2022, 10:50 Aaron Rainbolt 
wrote:

Thanks, that's what I needed to know! Virt-manager is more
than sufficient for my needs, and I can always cough up the
$150-$200 if I really want to do VMware testing.

Thank you for your time and help!

On Fri, May 13, 2022 at 3:51 AM Shane O'Sullivan
 wrote:

It's a breach of the EULA. I would highly recommend
installing virt-manager as a suitable alternative.

On Fri 13 May 2022, 08:17 Aaron Rainbolt,
 wrote:

I am digging deep into the world of Ubuntu development
and am trying to make sure my alpha and beta testing
is as effective as possible. I also don't want to cash
out an arm and a leg for expensive software to do so.
I've been using virt-manager (QEMU/KVM) for testing on
virtual machines, and while things seem to be going
well, I'd like to test on other hypervisors too for
the sake of catching as many bugs as possible.

VMware provides their Workstation Player product for
free, *for non-commercial use.* Problem is, I can't
figure out if using VMware for Ubuntu testing would be
considered commercial use. One one hand, I'm not a
Canonical employee, nor am I using VMware for
employment purposes, so that would be non-commercial,
but on the other hand, I'm helping a large enterprise
build an OS that is used for commercial purposes, so
that seems like commercial use.

Do any of y'all do QA testing in the free version of
VMware Workstation Player? Does anyone know if this
is a legal use of VMware?

Thank you for your help and time.

(Note: I /think/ these kinds of questions are what
this mailing list is for, but if I'm misguided and
should have sent this to ubuntu-devel-discuss, please
let me know and I'll direct these kinds of questions
there instead.)
-- 
ubuntu-devel mailing list

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

-- 
ubuntu-devel mailing list

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


-- 
ubuntu

[Bug 1922342] Re: Impish live session takes ages to boot on BIOS systems

[Thomas Schmitt]

Hi,

i have to correct a statement of mine in #104:

> Last year this worked only once, because casper added the partition again
> during "persistent partition creation". This could be fixed now:
>  https://bugs.launchpad.net/ubuntu-cdimage/+bug/1899308/comments/60

It's probably not fixed.
The comment by Steve Langasek rather announces the problem which José 
Marinho experienced:
casper was probably adjusted to create the boot flag when creating the
persistent partition. Originally it did not preserve it.

We will see what the j3400 does on first and second boot attempt.

Have a nice day :)

Thomas

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1922342

Title:
  Impish live session takes ages to boot on BIOS systems

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-release-notes/+bug/1922342/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1973622] [NEW] unable to start repo tool

[Thomas Epperson]

Public bug reported:

When starting the repo command (with no arguments) in a initialized repo
folder, it fails to start. Here is the traceback of the failure output
on the shell.

Traceback (most recent call last):
  File "/home/tepperson/yocto/.repo/repo/main.py", line 56, in 
from subcmds.version import Version
  File "/home/tepperson/yocto/.repo/repo/subcmds/__init__.py", line 35, in 

mod = __import__(__name__,
  File "/home/tepperson/yocto/.repo/repo/subcmds/help.py", line 20, in 
from formatter import AbstractFormatter, DumbWriter
ModuleNotFoundError: No module named 'formatter'

** Affects: repo (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: 22.04 ubuntu

** Tags added: 22.04 ubuntu

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1973622

Title:
  unable to start repo tool

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/repo/+bug/1973622/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1922342] Re: Impish live session takes ages to boot on BIOS systems

[Thomas Schmitt]

Hi,

Chris Guiver wrote:
> BOOT2:  LIVE
> 00:25 secs & screen blanks & messages
> 00:35 plymouth visible
> 01:11 message(s) again & plymouth gone
> 02:23 system fully-operational

The overall boot time is still very long. But no particular stage stands
out as the big time waster.

>...> motion computing j3400

This one is possibly allowed to be somewhat slow.

> Ubuntu Desktop 22.04 LTS
> 08:01 screen blanked

I really wonder which side, GRUB or vmlinuz, causes this delay.

After wasting time with clueless experiments i re-read what we have and
what i vastly forgot.

--
This prompts another test request @ Chris Guiver:

Does it help to remove MBR partition 2 similarly to what i proposed a year
ago to José Marinho and what helped to boot:

  # (When replacing the "X", take care not to zap your system disk)
  STICK=/dev/sdX
  dd if=/dev/zero bs=1 count=16 of="$STICK" conv=notrunc seek=462

Last year this worked only once, because casper added the partition again
during "persistent partition creation". This could be fixed now:
  https://bugs.launchpad.net/ubuntu-cdimage/+bug/1899308/comments/60
If not fixed: A second dd treatment after the first boot was not overridden
by casper in the next Live system run.

--
Summary of my re-reading:

José Marinho wrote in
https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1922342/comments/35
> With the iso without any change:
> - Plymouth --> 7 minutes
> - Desktop environment --> 7 minutes 50 seconds
> Marking the first partition as bootable legacy BIOS:
> - Plymouth --> 54 seconds.
> - Desktop environment --> 1 minute 45 seconds
> Without marking any partition as bootable but changing the partition table 
> from GPT to MBR:
> - Plymouth --> 25 seconds.
> - Desktop environment --> 1 minute 20 seconds.

So we had already a good suspect for a delay of about 6 minutes.

Then we had the red herring of these lines in grub.cfg which for a while
seemed to be the culprit. I proposed a change in #39. But in #55,
José Marinho finally reported that the intermediate success was rather
due to inadverted partition table changes during the experients.

In #60 i propose to remove partition 2 from the MBR.
(This partition exists to lure in some HP laptops which want to see a
boot flag. This flag is forbidden for the GPT-announcing partition slot.)
José Marinho reports in #61 that this helps for one time booting, but not
for further attempts to boot.
In #70 i demonstrated that the software in the ISO manipulates the MBR
partition table of the stick.
In #73 i point to "casper" and its "persistent partition creation".

Chris Guiver introduced the j3400 tablet to us in #76.

Chris Guiver and Brian Murray let GRUB be verbose in #82 and #83.
It prints:
> "Booting a command list"
Screenshots are at #84 and #85.

Since the messages do not look to me like from a Linux kernel, it appears
that the delay is in GRUB.
We could ask at grub-devel for help. But it happens only to a few (old ?)
machines and it is about the boot flag, which at least Vladimir Serbinko 
rejected firmly when the HP laptops showed up which don't boot without it.

So the conclusion of "tlk (sarcasticskull)" in #91 is noteworthy:
> kinda frustrating that the fixes/kludges for both "advanced" EFI and
> legacy crap "proprietary" systems suddenly make booting an Ubuntu LTS
> live ISO impossible

I thought i had read the proposal to have two flavors of Live ISOs
but cannot find currently it in this giant bug report.
So without the claim to have invented it myself:
Have an EFI+BIOS flavor without the problematic boot flag in the MBR,
and an Odd-Old-BIOS flavor without GPT and with boot flag.

Most machines, including those which are affected by this bug would boot
by the EFI+BIOS ISOs. Only a few would need Odd-Old-BIOS.

-
A peek over the fence:

Fedora considers to adopt for its ISOs the GPT partition layout without
boot flag in MBR:
  
https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/2G3DQ5SGCV5DSD7NPVXU3KAKQ57BOXVU/
They found a Dell XPS 15 L502X laptop which does not boot from this
but also does not boot if a boot flag MBR partition is added.
Nevertheless it looks like Fedora is willing to leave it behind together
with the HP laptops which want the boot flag.

Have a nice day :)

Thomas

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1922342

Title:
  Impish live session takes ages to boot on BIOS systems

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-release-notes/+bug/1922342/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1973482] Re: kernel 4.15.0.177 break everything on Dell XPS 15 9570

[Thomas Lehmann]

** Attachment added: "lspci-dell-latitude-7300.txt"
   
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1973482/+attachment/5590019/+files/lspci-dell-latitude-7300.txt

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1973482

Title:
  kernel 4.15.0.177 break everything on Dell XPS 15 9570

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1973482/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1973482] Re: kernel 4.15.0.177 break everything on Dell XPS 15 9570

[Thomas Lehmann]

Same issue with Dell Latitude 7300. Device detection like disks fail,
apparently randomly. Some media keys don't work, Wifi was OK.

Previous kernel build is fine.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1973482

Title:
  kernel 4.15.0.177 break everything on Dell XPS 15 9570

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1973482/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1973482] Re: kernel 4.15.0.177 break everything on Dell XPS 15 9570

[Thomas Lehmann]

** Attachment added: "cpuinfo-dell-latitude-7300.txt"
   
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1973482/+attachment/5590018/+files/cpuinfo-dell-latitude-7300.txt

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1973482

Title:
  kernel 4.15.0.177 break everything on Dell XPS 15 9570

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1973482/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 604357] Re: Ubuntu's printing queue is not user friendly

[Ruby Thomas]

With this issue I was facing another one issue like my hp docking system
is not working. But after long time I found the best solution from this
website:

https://internettablettalk.com/fix-hp-docking-station-not-working/

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/604357

Title:
  Ubuntu's printing queue is not user friendly

To manage notifications about this bug go to:
https://bugs.launchpad.net/system-config-printer/+bug/604357/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs