Re: Call for confirmation of LTSness of flavours for bionic

[flocculant]

On 13/04/18 22:24, Adam Conrad wrote:

So, before we go baking in the support headers in the final release of
bionic, we should double-check with all the flavour leads what their
support commitment plans are for 18.04.  Currently, what we have live
in production is:

5 Year LTS:
   - Ubuntu Base / Cloud / Desktop / Server
3 Year LTS:
   - Kubuntu
   - Lubuntu
   - Ubuntu Budgie
   - Ubuntu MATE
   - UbuntuKylin
   - Xubuntu
Not LTS:
   - UbuntuStudio
   - Lubuntu Next

It is highly recommended that flavours that choose to be LTS remain
with a 3 years cycle, as that gives you an overlap to get users to
the next LTS without committing to, frankly, a much longer support
length than you think five years is until you've done it. ;)

If we could get people to sound off with an "I represent $flavour, and
I confirm that we intend to support 18.04 for 3 years" (or, obviously,
let us know instead if you don't intend to do so, so we can adjust),
that would be lovely.

... Adam


Xubuntu Release Team ack for us doing LTS for Bionic

Cheers

Kev


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

Re: Ubuntu Meta-Release & Meta-Release-LTS

[Steve Langasek]

On Sun, Apr 08, 2018 at 10:45:37PM -0700, Triston Line wrote:
> Hi Ubuntu Release Team,

> I'm setting up a local mirror to support upgrading using the mirror and I
> haven't been able to test upgrading yet due to the
> changelogs.ubuntu.com/meta-relase and meta-release-lts files haven't been
> updated to include Ubuntu 18.04. Thank you if I've missed a memo or
> overlooked any research results that would explain the delay in the file
> update.

These files are updated only with the list of stable releases. 
http://changelogs.ubuntu.com/meta-release can be expected to be updated
after 18.04 GA near the end of this month, and
http://changelogs.ubuntu.com/meta-release-lts can be expected to be updated
after the 18.04.1 point release in July.

> PS
> Yes I've tried do-release-upgrade -d without success, if I may have missed
> something I'd love to hear it as I'm only network engineer, not a full time
> systems administrator. Thanks, again.

This is the expected method for testing upgrades to pre-release versions of
Ubuntu, using http://changelogs.ubuntu.com/meta-release-development and
http://changelogs.ubuntu.com/meta-release-lts-development.  It is generally
known to be working.  You don't say here what issue you encountered with
this command, but that's where you'll need to look at debugging.

-- 
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 Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


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

Re: Call for confirmation of LTSness of flavours for bionic

[foss.freedom]

I represent Ubuntu Budgie and
I confirm that we intend to support 18.04 for 3 years

David (project lead)

On Fri, 13 Apr 2018, 22:25 Adam Conrad,  wrote:

> So, before we go baking in the support headers in the final release of
> bionic, we should double-check with all the flavour leads what their
> support commitment plans are for 18.04.  Currently, what we have live
> in production is:
>
> 5 Year LTS:
>   - Ubuntu Base / Cloud / Desktop / Server
> 3 Year LTS:
>   - Kubuntu
>   - Lubuntu
>   - Ubuntu Budgie
>   - Ubuntu MATE
>   - UbuntuKylin
>   - Xubuntu
> Not LTS:
>   - UbuntuStudio
>   - Lubuntu Next
>
> It is highly recommended that flavours that choose to be LTS remain
> with a 3 years cycle, as that gives you an overlap to get users to
> the next LTS without committing to, frankly, a much longer support
> length than you think five years is until you've done it. ;)
>
> If we could get people to sound off with an "I represent $flavour, and
> I confirm that we intend to support 18.04 for 3 years" (or, obviously,
> let us know instead if you don't intend to do so, so we can adjust),
> that would be lovely.
>
> ... Adam
>
> --
> Ubuntu-release mailing list
> Ubuntu-release@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
>
-- 
Ubuntu-release mailing list
Ubuntu-release@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-release

Ubuntu Meta-Release & Meta-Release-LTS

[Triston Line]

Hi Ubuntu Release Team,

I'm setting up a local mirror to support upgrading using the mirror and I
haven't been able to test upgrading yet due to the
changelogs.ubuntu.com/meta-relase and meta-release-lts files haven't been
updated to include Ubuntu 18.04. Thank you if I've missed a memo or
overlooked any research results that would explain the delay in the file
update.

I hope this email doesn't come across as harassment haha, I'm in no rush
just hope nothing's been forgotten. Thanks everyone for all your hard work.

Triston Line


PS
Yes I've tried do-release-upgrade -d without success, if I may have missed
something I'd love to hear it as I'm only network engineer, not a full time
systems administrator. Thanks, again.

*Also launchpad is down* for one reason or another at the time of writing.
Tested locally, cellulary and had a friend and a foreign website give it a
go, nada.

91.189.95.83 or http://ppa.launchpad.net/

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

Re: xchat and hexchat

[Gianfranco Costamagna]

Hello Steve and all,


>Lacking quorum, there was no actual TB meeting the other week.  However, as
>I noted on IRC, I also don't consider this a matter requiring the Technical
>Board's input.  In the first instance, this falls within the purview of the
>archive team, and I'm happy for us to field it as such.


I agree, thanks for simplifying the things :)
>If there are concerns about the archive team's decision here, that decision
>may always be appealed to the TB.
>
>The original bug report,
>, was filed
>per my request on #ubuntu-release[1], but I overlooked the actual filing
>which came with some delay after the IRC discussion.
>
>This does not mean I agree that the package should be removed, but as you, I
>think it's important to have this discussion and take a decision.


thanks
>I do have concerns about the quality of this software, as well as about the
>maintainer's response to the concerns that have been raised.  Comments
>inline:


lets try to answer

>An IRC client, in its default mode of operation, requires zero>authentication 
>of a remote server.  The server must therefore be considered
>untrusted and potentially hostile.  Even *with* authentication, a remote
>server could be compromised.
>
>Any security vulnerability involving a network client failing to validate
>input from a remote source is a significant one.
>
>And in my opinion, any network client whose upstream maintainer didn't
>consider such vulnerabilities worthy of serious attention should not be
>included in a stable Ubuntu release.
>
>So please don't try to argue for xchat's inclusion by downplaying the
>significance of security vulnerabilities.


ack here, but sorry if I made this false assumption. the mean of that
sentence was not "don't care because internet is broken or evil",
but more a "hey, such vulnerabilities exists in probably *all* irc clients,
including hexchat and others, at least in stable releases. You can do fuzzy
testing against the versions to check them.

So, while I *always* fixed CVEs on my packages, I also think we should focus
more to real bugs, not something discovered by a fuzzy test, that affects 
probably
most irc clients, with an userbase really low, and with a crash as effect and 
not
a personal data leak or similar.

My assumption was just to mention that a "crash" for a vulnerability is 
something
we might really like at the end :)

>I have no problem in principle with a package that is orphaned upstream and
>is now maintained only in Debian/Ubuntu.  There have certainly been many
>other examples of this, and such packages are not categorically worse than
>those that have a separate upstream.
>
>My understanding is that most former xchat users find hexchat to be a
>reasonable replacement.  Can you explain why you do not?


it is, but new features breaks it from time to time (eg. 1.14.0 vs 1.14.1, the 
latter
has been pushed because of the previous one not being suitable for usage), 
moreover
we still don't have a clean upgrade path from xchat to hexchat, at least for 
configuration files.

People might want to keep it, until we smoothly upgrade them and move around 
configuration.
(this is something somewhat slowly ongoing=

>I'm afraid I don't agree at all with this argumentation.  For better or
>worse, it is a fairly common practice across Free Software (and otherwise!)
>for security vulnerabilities to be fixed by upstreams without disclosing
>these were security vulnerabilities; and this doesn't have to indicate ill
>intent on the part of the upstream.  Sometimes the upstream has nothing more
>than a vague sense that a bug might be exploitable and it's not worth the
>effort to prove it.
>
>I don't think it in any way disqualifies hexchat for inclusion in stable
>Ubuntu releases to know that upstream has fixed security bugs without going
>through a particular disclosure process.  It is not even the responsibility
>of the upstream maintainer to notify Ubuntu of such vulnerabilities (though
>we certainly welcome having such notifications!), and for packages in
>universe, many known vulnerabilities will unfortunately remain unfixed
>anyway.  It is definitely not the upstream's responsibility to disclose the
>details of security vulnerabilities for the benefit of an unrelated fork
>from an older codebase.


sure, this wasn't a really strong point on my side :)

>I do question the wisdom of maintaining software exclusively via
>debian/patches over the long term, if indeed that's what you're doing here. 
>But that's my personal opinion as a developer, and has nothing to do with
>whether the package, today, should be removed from the release.


ack

>What, in practice, do you believe this maintenance will consist of?  Are you
>planning to monitor CVE activity of related codebases to watch for issues
>that may also affect xchat, or will this maintenance be entirely reactive in
>response to critical bug reports?


yes, as I'm doing with all the 

Re: Ubuntu Meta-Release & Meta-Release-LTS

[Triston Line]

And would you look at that, suddenly, a wild ppa.launchpad.net appeared.

Triston


ps
(It's back up!) No that wasn't the purpose of the original email

On Sun, Apr 8, 2018 at 10:45 PM, Triston Line  wrote:

> Hi Ubuntu Release Team,
>
> I'm setting up a local mirror to support upgrading using the mirror and I
> haven't been able to test upgrading yet due to the
> changelogs.ubuntu.com/meta-relase and meta-release-lts files haven't been
> updated to include Ubuntu 18.04. Thank you if I've missed a memo or
> overlooked any research results that would explain the delay in the file
> update.
>
> I hope this email doesn't come across as harassment haha, I'm in no rush
> just hope nothing's been forgotten. Thanks everyone for all your hard work.
>
> Triston Line
>
>
> PS
> Yes I've tried do-release-upgrade -d without success, if I may have
> missed something I'd love to hear it as I'm only network engineer, not a
> full time systems administrator. Thanks, again.
>
> *Also launchpad is down* for one reason or another at the time of
> writing. Tested locally, cellulary and had a friend and a foreign website
> give it a go, nada.
>
> 91.189.95.83 or http://ppa.launchpad.net/
> 
>
-- 
Ubuntu-release mailing list
Ubuntu-release@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-release

Call for confirmation of LTSness of flavours for bionic

[Adam Conrad]

So, before we go baking in the support headers in the final release of
bionic, we should double-check with all the flavour leads what their
support commitment plans are for 18.04.  Currently, what we have live
in production is:

5 Year LTS:
  - Ubuntu Base / Cloud / Desktop / Server
3 Year LTS:
  - Kubuntu
  - Lubuntu
  - Ubuntu Budgie
  - Ubuntu MATE
  - UbuntuKylin
  - Xubuntu
Not LTS:
  - UbuntuStudio
  - Lubuntu Next

It is highly recommended that flavours that choose to be LTS remain
with a 3 years cycle, as that gives you an overlap to get users to
the next LTS without committing to, frankly, a much longer support
length than you think five years is until you've done it. ;)

If we could get people to sound off with an "I represent $flavour, and
I confirm that we intend to support 18.04 for 3 years" (or, obviously,
let us know instead if you don't intend to do so, so we can adjust),
that would be lovely.

... Adam

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

New component-mismatches for source universe -> main

[process-component-mismatches-diff]

The following universe packages have new reverse dependencies
in main or got seeded. They need to get a MainInclusionReport and be
promoted, or the reverse dependencies in main need to be dropped:

 
  o networkd-dispatcher: networkd-dispatcher
[Reverse-Recommends: systemd (MAIN)]

Please see http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
for the full report.

Please contact https://launchpad.net/~ubuntu-archive for problems with this
notification.

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