Monday, March 25th, the DMB voted to grant Rik Mills (acheronuk) MOTU privileges.
Congratulations, Rik !
On behalf of the DMB,
Eric Desrochers
Congratulations, Rik !
On behalf of the DMB,
Eric Desrochers
Monday, 25 March 2019
Thursday, 21 March 2019
Re: More diagnostics data from desktop
To whom it may concern:
This proposal was brought to my attention by "The Linux Gamer" on
YouTube, and had a few thoughts on this proposed feature. If this is
the wrong place to make suggestions on this, I apologize.
1) The feature should be "opt-in", as in, disabled/unchecked by
default, so that users who aren't paying close attention don't
unwittingly enable the feature.
2) There should be separate opt-in boxes, one for data about the
installation and general hardware info, the second for the ongoing
collection of data regarding installed packages, software crashes, etc.
3) If the user opts in to either of these, it should be clearly
outlined during the installation process exactly what kind of
information is collected instead of a generic message.
4) There should be an area within the settings to disable, or re-
enable, the feature at a later date, again containing a detailed list
of exactly what is contained in the reports. "I" don't mind editing a
config file, but many people who use Ubuntu do so because it is user
friendly with minimal "required" time spent in the terminal, so having
a graphical way to enable or disable the telemetry data is important in
my opinion.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Marcus Dean Adams
"Civilization is the limitless multiplication
of unnecessary necessities."
-- Mark Twain
This proposal was brought to my attention by "The Linux Gamer" on
YouTube, and had a few thoughts on this proposed feature. If this is
the wrong place to make suggestions on this, I apologize.
1) The feature should be "opt-in", as in, disabled/unchecked by
default, so that users who aren't paying close attention don't
unwittingly enable the feature.
2) There should be separate opt-in boxes, one for data about the
installation and general hardware info, the second for the ongoing
collection of data regarding installed packages, software crashes, etc.
3) If the user opts in to either of these, it should be clearly
outlined during the installation process exactly what kind of
information is collected instead of a generic message.
4) There should be an area within the settings to disable, or re-
enable, the feature at a later date, again containing a detailed list
of exactly what is contained in the reports. "I" don't mind editing a
config file, but many people who use Ubuntu do so because it is user
friendly with minimal "required" time spent in the terminal, so having
a graphical way to enable or disable the telemetry data is important in
my opinion.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Marcus Dean Adams
"Civilization is the limitless multiplication
of unnecessary necessities."
-- Mark Twain
Tuesday, 19 March 2019
Re: going ahead of Debian with a dfsg orig tarball
On Tue, Mar 19, 2019 at 02:19:00PM -0300, Andreas Hasenack wrote:
> I find myself in the situation where we want to go ahead of debian for
> a package (samba), but it's a dfsg tarball. Debian doesn't have it
> anywhere yet, so I produced the tarball according to the exclude rules
> in debian/gbp.conf.
>
> I'm wondering, however, if some mistake happens, or something else,
> and the tarball I produce has a different hash than the tarball that
> Debian will eventually produce. Since my upload will be in Ubuntu
> already, what will happen when Launchpad will try to ingest Debian's
> upload, and finds out the orig tarball has a different md5, but the
> same name as the Ubuntu one?
> I find myself in the situation where we want to go ahead of debian for
> a package (samba), but it's a dfsg tarball. Debian doesn't have it
> anywhere yet, so I produced the tarball according to the exclude rules
> in debian/gbp.conf.
>
> I'm wondering, however, if some mistake happens, or something else,
> and the tarball I produce has a different hash than the tarball that
> Debian will eventually produce. Since my upload will be in Ubuntu
> already, what will happen when Launchpad will try to ingest Debian's
> upload, and finds out the orig tarball has a different md5, but the
> same name as the Ubuntu one?
If that happens, then it won't be possible to sync the Debian package,
and you'll have to use "syncpackage -F" to work around that (assuming
there are no other Ubuntu changes; if there are, then you can just merge
manually instead).
> To avoid that, I previously mangled the name of our orig tarball to
> use ...+dfsg~ubuntu-0ubuntu1 (i.e., I added the ~ubuntu bit after
> +dfsg), but that looks ugly.
I suppose that works well enough. It wouldn't be the first package
version to have multiple "ubuntu" substrings.
> Is there some recommended way of handling this, or am I just planning
> too much for something that won't be an issue?
I'd recommend talking to your Debian counterpart(s) to see if it's
possible to agree in advance on a particular orig tarball representation
of this upstream release.
--
Colin Watson [cjwatson@ubuntu.com]
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
going ahead of Debian with a dfsg orig tarball
Hi,
I find myself in the situation where we want to go ahead of debian for
a package (samba), but it's a dfsg tarball. Debian doesn't have it
anywhere yet, so I produced the tarball according to the exclude rules
in debian/gbp.conf.
I'm wondering, however, if some mistake happens, or something else,
and the tarball I produce has a different hash than the tarball that
Debian will eventually produce. Since my upload will be in Ubuntu
already, what will happen when Launchpad will try to ingest Debian's
upload, and finds out the orig tarball has a different md5, but the
same name as the Ubuntu one?
To avoid that, I previously mangled the name of our orig tarball to
use ...+dfsg~ubuntu-0ubuntu1 (i.e., I added the ~ubuntu bit after
+dfsg), but that looks ugly.
Is there some recommended way of handling this, or am I just planning
too much for something that won't be an issue?
Thanks!
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Thursday, 14 March 2019
Re: Re-inclusion of systemtap-sdt-dev in main
Hi Trent,
On Tue, Mar 12, 2019 at 01:48:59PM +0800, Trent Lloyd wrote:
> I am looking to add support for user-space probes (SDT) to Python (and
> potentially other applications - node, perl, etc have all grown support for
> this) so that we can use both Perf and BPF tools to trace and profile
> interpreted languages (Ref LP #1818778) at runtime.
> This requires a Build-Dependency on systemtap-sdt-dev. This previously had
> a MIR request approved and was in main in trusty, however it seems the
> package it was required for (ust) was moved back to universe before xenial
> and so both ust and systemtap-sdt-dev reverted to universe for xenial.
> Previous MIR:
> https://bugs.launchpad.net/ubuntu/+source/systemtap/+bug/1203590
> Can someone confirm for me if I need to file a new MIR for systemtap or if
> it would still be considered under the previous approval but just has no
> dependency to pull it in?
I have no problem with re-promoting this to main without a separate MIR.
Also, if you're only using systemtap-sdt-dev at build time and this doesn't
result in a runtime dependency, there may not be anything needing MIRed
anyway. Build-Dependencies no longer have to be in main.
--
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/
slangasek@ubuntu.com vorlon@debian.org
On Tue, Mar 12, 2019 at 01:48:59PM +0800, Trent Lloyd wrote:
> I am looking to add support for user-space probes (SDT) to Python (and
> potentially other applications - node, perl, etc have all grown support for
> this) so that we can use both Perf and BPF tools to trace and profile
> interpreted languages (Ref LP #1818778) at runtime.
> This requires a Build-Dependency on systemtap-sdt-dev. This previously had
> a MIR request approved and was in main in trusty, however it seems the
> package it was required for (ust) was moved back to universe before xenial
> and so both ust and systemtap-sdt-dev reverted to universe for xenial.
> Previous MIR:
> https://bugs.launchpad.net/ubuntu/+source/systemtap/+bug/1203590
> Can someone confirm for me if I need to file a new MIR for systemtap or if
> it would still be considered under the previous approval but just has no
> dependency to pull it in?
I have no problem with re-promoting this to main without a separate MIR.
Also, if you're only using systemtap-sdt-dev at build time and this doesn't
result in a runtime dependency, there may not be anything needing MIRed
anyway. Build-Dependencies no longer have to be in main.
--
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/
slangasek@ubuntu.com vorlon@debian.org
Extended Security Maintenance for Ubuntu 14.04 (Trusty Tahr) begins April 25 2019
Ubuntu announced its 14.04 (Trusty Tahr) release almost 5 years ago, on
April 17, 2014. As with the earlier LTS releases, Ubuntu committed to
ongoing security and critical fixes for a period of 5 years. The standard
support period is now nearing its end and Ubuntu 14.04 will transition to
Extended Security Maintenance (ESM) on Thursday, April 25th, 2019.
April 17, 2014. As with the earlier LTS releases, Ubuntu committed to
ongoing security and critical fixes for a period of 5 years. The standard
support period is now nearing its end and Ubuntu 14.04 will transition to
Extended Security Maintenance (ESM) on Thursday, April 25th, 2019.
Users are encouraged to evaluate and upgrade to our latest 18.04 LTS
release via 16.04. The supported upgrade path from Ubuntu 14.04 is via
Ubuntu 16.04. Instructions and caveats for the upgrades may be found at:
https://help.ubuntu.com/community/XenialUpgrades for Ubuntu 16.04 and
https://help.ubuntu.com/community/BionicUpgrades for Ubuntu 18.04.
Ubuntu 16.04 and 18.04 continue to be actively supported with security
updates and bug fixes. All announcements of official security updates for
Ubuntu releases are sent to the ubuntu-security-announce mailing list,
information about which may be found here:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-security-announce
Canonical provides Extended Security Maintenance for Ubuntu 14.04 LTS to
customers through Ubuntu Advantage. The announcement including details
about how and where to purchase extended support can be found here:
https://blog.ubuntu.com/2019/02/05/ubuntu-14-04-trusty-tahr
https://www.ubuntu.com/esm
Since its launch in October 2004, Ubuntu has become one of the most
highly regarded Linux distributions with millions of users in homes,
schools, businesses and governments around the world. Ubuntu is Open
Source software, costs nothing to download, and users are free to
customise or alter their software in order to meet their needs.
On behalf of the Ubuntu Release Team,
Adam Conrad
--
ubuntu-announce mailing list
ubuntu-announce@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-announce
Tuesday, 12 March 2019
Re: New PPU uploader - Ross Gammon
On 3/12/19 11:20 AM, Lukasz Zemczak wrote:
> Please congratulate Ross on his successful PPU uploader application!
> Please congratulate Ross on his successful PPU uploader application!
Congrats Ross!
Mark
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Subscribe to:
Posts (Atom)