Re: Bileto

[Dan Streetman]

On Mon, Jun 6, 2022 at 5:18 PM Sergio Durigan Junior
 wrote:
>
> On Thursday, June 02 2022, Dan Streetman wrote:
>
> > How do I get access to bileto? Everyone in canonical product engineering
> > seems to use this system but I've never had access. Is it restricted to
> > only some canonical employees?
>
> Hey Dan,
>
> I remember gaining access to bileto automatically when I became a Core
> Dev.  I didn't have to ask permission to anyone.

Looking at the LP team that (I think?) controls Bileto access, i.e.
~bileto-users, I appear to be already in that team...which I never
realized. However, I've even if I do magically have access to use
Bileto, I never knew that, and I still don't know how I can actually
'use' (i.e. upload anything to) it...

is there some docs on how to 'use' bileto?

>
> Cheers,
>
> --
> Sergio
> GPG key ID: E92F D0B3 6B14 F1F4 D8E0  EB2F 106D A1C8 C3CB BF14

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

Bileto

[Dan Streetman]

How do I get access to bileto? Everyone in canonical product engineering
seems to use this system but I've never had access. Is it restricted to
only some canonical employees?

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

Re: Call for votes: Developer Membership Board restaffing

[Dan Streetman]

On Tue, Mar 29, 2022 at 6:02 AM Robie Basak  wrote:
>
> On Wed, Mar 23, 2022 at 12:51:52PM +0100, Christian Ehrhardt wrote:
> > If you happen to activate the "wrong" email you'll just see:
> >
> > ```
> >   Email address successfully activated.
> > ```
> >
> > But if you activate the right one (just as Robie said, usually the
> > @ubuntu.com one) you'd in the Web UI of CIVS right after clicking
> > "Complete activation" see this:
> >
> > ```
> > Email address successfully activated.
> >   Pending poll invitations:
> > Ubuntu Developer Membership Board restaffing
> > ```
> >
> > The latter line is a link leading you to your vote.
>
> Thank you Christian for detailing this. Hopefully this has helped others
> vote.
>
> So far the turnout is considerably lower than the previous election two
> years ago. Last time there were 54/173 votes cast at the time the poll
> closed. For the CIVS poll in progress I can't see who voted (or how) but
> the control page does show me the count. So far we have 23/174.
>
> We've had a couple of hurdles:
>
> 1) This extra opt-in step means that the electorate no longer get the
> poll request directly to their inbox. We're relying on them seeing the
> ubuntu-devel-announce@ notifications, or subsequent traffic to
> ubuntu-devel@.
>
> 2) Recently Gmail seems to have adjusted things which has caused
> deliverability problems to @gmail.com addresses (and presumably other
> addresses hosted by Google). IS has made some adjustments to try to
> help, but it's unclear to me if they worked because overnight I received
> ~373 "unsubscribe" notifications to ubuntu-devel-owner@ all at once,
> predominantely relating to @gmail.com addresses. It seems likely to me
> that these are a result of the deliverability problems. So it's not
> clear to me that all of the electorate is actually even aware of the
> election. Of course there are surely many more ubuntu-devel@ subscribers
> than those eligible to vote, so the number of unsubscribes doesn't
> actually mean anything.
>
> I'd appreciate feedback on how to proceed.

Where are the rules/policies written down about how elections should
be handled? We should have the process written down somewhere so there
is not ambiguity like this.

> For example, together with
> some specific action to draw the attention of the electorate, I could
> extend the voting period if that would be considered helpful.
>
> On the other hand, it would be helpful to get the replacement DMB
> members resolved as soon as possible. Perhaps the current vote count can
> be considered enough to not make a big difference to the outcome, given
> that there's no particular reason for bias in those that might not have
> received the announcement?
>
> 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

Re: Ubuntu LTS20.04 - wireguard package

[Dan Streetman]

On Tue, Jan 11, 2022 at 12:35 PM Jeffrey Walton  wrote:
>
> On Tue, Jan 11, 2022 at 8:36 AM Dan Streetman  wrote:
> > ...
> > > Fedora has a 6 month release cycle. Each version you are on has the
> > > latest releases of its packages and gets full updates. And in 6 months
> > > you move onto the next stable version. At the 6 month release in the
> > > life cycle, you simply run dnf-system-upgrade [1] and you are on the
> > > next version of Fedora. dnf-system-upgrade is a lot like a Ubuntu
> > > dist-upgrade.
> >
> > Just to clarify, what you are describing about Fedora is EXACTLY the
> > same for Ubuntu...6 month release cycle, latest packages in each
> > release, full updates (for at least 9 months), upgrade with a single
> > command at each 6 month release. The 'dnf-system-upgrade' sounds more
> > like the 'do-release-upgrade' command, not 'apt dist-upgrade' (though
> > both are similar).
>
> Yes, you're right. do-release-upgrade looks like the similar command.
>
> Do you know if do-release-upgrade will move from one LTS version to
> another? I usually select Ubuntu LTS when I want long term stability,
> like over 3 or 5 years. In fact, my main desktop machine is Ubuntu
> 18.04 LTS.

Yes, the /etc/update-manager/release-upgrades file contains a 'Prompt'
setting that controls if do-release-upgrade will upgrade to the next
LTS release or the next 'normal' release.

This blog post has some more detailed info; though the post is
obviously almost 2 years old, I think it's all still relevant/correct:
https://ubuntu.com/blog/how-to-upgrade-from-ubuntu-18-04-lts-to-20-04-lts-today


>
> Fedora does not really offer long term stability. Fedora is more
> suited for the latest stable release every 6 months. Select it when
> you want as close to the bleeding edge as possible while staying
> stable.
>
> Jeff

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

Re: Ubuntu LTS20.04 - wireguard package

[Dan Streetman]

On Mon, Jan 10, 2022 at 6:17 PM Jeffrey Walton  wrote:
>
> On Mon, Jan 10, 2022 at 2:02 PM Filip Menke  wrote:
> >
> > Is there a reason why the wireguard package is outdated and no updates are 
> > available through the standard update process(apt-get update / upgrade)?
> >
> > Users must update the package manually and from a security perspective a 
> > VPN server should be always up to date otherwise the system could be 
> > vulnerable..
>
> Related, if you want the latest version of a package like Wireguard
> (or GCC, or Python, or Perl, ...), then you might want to look at
> Fedora.
>
> Fedora has a 6 month release cycle. Each version you are on has the
> latest releases of its packages and gets full updates. And in 6 months
> you move onto the next stable version. At the 6 month release in the
> life cycle, you simply run dnf-system-upgrade [1] and you are on the
> next version of Fedora. dnf-system-upgrade is a lot like a Ubuntu
> dist-upgrade.

Just to clarify, what you are describing about Fedora is EXACTLY the
same for Ubuntu...6 month release cycle, latest packages in each
release, full updates (for at least 9 months), upgrade with a single
command at each 6 month release. The 'dnf-system-upgrade' sounds more
like the 'do-release-upgrade' command, not 'apt dist-upgrade' (though
both are similar).

>
> I really like Fedora's model, the use of SELinux in enforcing mode,
> and Fedora's desire to provide the latest versions of software. In
> fact, I run Fedora Workstations to test the latest GCC compilers, and
> Fedora Servers when I need a web server.
>
> I no longer bother with CentOS or Red Hat servers. I can't stand that
> antique software that makes you use Software Collections (SCL) to get
> something semi-modern. I gave up on CentOS and Red Hat servers when
> trying to get Mediawiki running on them. CentOS and Red Hat servers
> with their old software was just too much work.
>
> I also use Ubuntu workstations and servers. But every now and again
> you want the latest software for a server, and that's when you want to
> consider Fedora.
>
> [1] https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/
>
> Jeff
>
> --
> 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: firebird3.0 install on Ubuntu 16.04.7 LTS (Xenial Xerus)

[Dan Streetman]

On Sat, Apr 24, 2021 at 10:21 AM Thomas Ward  wrote:
>
> And once more, ESM rears its head.
>
> ESM comes with no community support.  Support for ESM releases is for *paid 
> Canonical support via Ubuntu Advantage subscriptions*.

Just to clarify this slightly, ESM does not come with any
(non-security) bug-fix support, even paid ESM. ESM provides updates to
fix security-related issues/bugs. Both community support, as well as
paid UA contract support (for non-security bug fixes), end when a
release reaches End of Standard Support.

> The Community Council clarified this with Canonical who will be putting out a 
> more descriptive document explaining ESM and this information.  None of the 
> prior releases RE: ESM had any details about End of Standard Support - thats 
> a new thing that was recently added to releases.  So yes ESM repos will get 
> you additonal security patches but it won't extend to community support - 
> that will require paid Canonical contracts.
>
> 16.04 to 18.04 is a valid upgrade path so d-r-u will work. But you will still 
> need to upgrade to 18.04 and I recommend doing that sooner than later.
>
>
> Thomas
>
>
>  Original message 
> From: Ralf Mardorf 
> Date: 4/24/21 10:09 (GMT-05:00)
> To: ubuntu-devel-discuss@lists.ubuntu.com
> Subject: Re: firebird3.0 install on Ubuntu 16.04.7 LTS (Xenial Xerus)
>
> On Fri, 23 Apr 2021 17:27:30 -0400, Thomas Ward wrote:
> >Be aware though: 16.04.7 goes past End of Standard Support this month
> >- you should consider upgrading 16.04 to 18.04 before the end of
> >standard support happens.
>
> Doesn't do-release-upgrade after April work anymore? I suspect that it
> at least does work until April 2023, when Ubuntu 18.04 standard support
> ends. If a release upgrade isn't needed, 16.04 should be (more or
> less) good until April 2024. Am I mistaken?
>
> "Is Ubuntu 16.04 LTS still supported beyond April 2021?
>
> Ubuntu 16.04 LTS will still be supported beyond its free initial
> five-year maintenance period in April 2021, as it transitions to the
> extended security maintenance phase - with three additional years of
> security ensured.
>
> Learn more about Ubuntu 16.04 LTS moving to ESM  ›
> Free for personal use
>
> Canonical provides Ubuntu Advantage Essential subscriptions, which
> include ESM, free of charge for individuals on up to 3 machines. For
> our community of Ubuntu members we will gladly increase that to 50
> machines. Your personal subscription will also cover Livepatch. Get ESM
> now" - https://ubuntu.com/security/esm
>
> --
> 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: default algorithm in package zram-config 0.5

[Dan Streetman]

On Mon, Jun 8, 2020 at 6:40 PM Mitch 74  wrote:
>
> I know about the setting, that's why I mentioned changing the default -
> lzo is a wee bit outdated now, while lz4 is built into the kernel now so
> there's little chance of it not working out of the box. Moreover it's
> not about changing the default in zram

Why do you want to change the default in Ubuntu but not in the upstream kernel?

> , only in the package zram-config
> (i.e. when setting it up).
>
> Le 09/06/2020 à 00:33, Dan Streetman a écrit :
> > On Mon, Jun 8, 2020 at 3:42 PM Mitch 74  wrote:
> >> Hello,
> >>
> >> Considering that now lz4 is by default enabled in kernel, wouldn't it be
> >> better to use it as a compression algorithm in zram instead of lzo?
> > the zram default upstream is still lzo (lzo-rle).  you can select zram
> > alg for each device, at /sys/block/zramN/comp_algorithm, before you
> > initialize it.
> >
> >> Regards
> >>
> >> Mitch 74
> >>
> >>
> >> --
> >> 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: default algorithm in package zram-config 0.5

[Dan Streetman]

On Mon, Jun 8, 2020 at 3:42 PM Mitch 74  wrote:
>
> Hello,
>
> Considering that now lz4 is by default enabled in kernel, wouldn't it be
> better to use it as a compression algorithm in zram instead of lzo?

the zram default upstream is still lzo (lzo-rle).  you can select zram
alg for each device, at /sys/block/zramN/comp_algorithm, before you
initialize it.

>
> Regards
>
> Mitch 74
>
>
> --
> 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: how sudo handles $HOME

[Dan Streetman]

On Thu, May 16, 2019 at 6:35 AM Carl Friis-Hansen
 wrote:
>
> On 5/16/19 3:03 AM, Alex Murray wrote:
> >
> > On Wed, 2019-05-15 at 02:42:56 +0930, Dan Streetman wrote:
> >
> >> in Ubuntu, sudo retains the calling user's $HOME
> >>
> >> this is different from upstream sudo as well as all other UNIXes and
> >> even the sudo documentation we provide.  Should we remove our custom
> >> patch that adds this behavior?
> >
> > I would argue that our current behaviour provides a more usable default
> > (eg. running vim via sudo uses your own configuration so you don't have
> > to maintain a copy of it in /root) and in the case of a machine with
> > multiple sudo users, they all get to use their own configuration rather
> > than a single configuration under /root.
> >
> > However, it does diverge from upstream and so for new users this creates
> > a surprising situation if they are used to and expect the upstream
> > behaviour - (see comments 6 and 7 in
> > https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/760140) - plus it
> > seems we do not document this change in the man page and so we are
> > creating even more surprises for our users.
> >
> >  From a security point of view I do not see any advantage from either
> > behaviour, so it is really more a usability question IMO.
> >
> >>
> >> for reference and more details on downsides of our current sudo behavior, 
> >> see:
> >> https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1556302
> >>
> >> Note that I have kind-of hijacked the bug, as I believe the issue is
> >> larger than the python-based example in that bug.
> >>
> >> Also as I commented in that bug, I do not recommend changing the
> >> behavior for existing releases.  But I do think we should change the
> >> behavior starting in Eoan and future releases.
> >
> > I agree if this is changed we should not try and SRU it back.
> >
> I would say let it remain user's home for editor configs.
> You could always use option -i in case you want root home.

That is a significant upside to current behavior; but please don't
forget about the downside of accessing editor configs under sudo:
root-owned editor config files, e.g.:
https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1556302/comments/9

For some users, this is a simple fix of running sudo chown.  For users
simply following online directions though, the errors resulting from
this can be quite frustrating and confusing.  Try googling for 'root
owned emacs.d' or 'root owned viminfo', e.g.:
http://blog.robertelder.org/vim-forgets-copy-buffer-on-reopen/

For those that commonly use fresh vms or containers, root-owned editor
config files can be a common occurance/annoyance.

>
> --
>-=oOOo=-
>  Carl Friis-Hansen
>  https://carl-fh.com/
>  https://dronehyr.se/
>  Phone: +46 372 775199
>-=oOOo=-
>
> --
> 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: how sudo handles $HOME

[Dan Streetman]

Good question.

I've cc'ed sudo-users, so the question to the upstream sudo list can
be summarized as:
How likely would it be for upstream sudo to add HOME to env_keep by default?

We ask because Ubuntu carries a patch that adds HOME to env_keep,
unlike the default upstream, or any other Linux/Unix.  We are
considering removing that patch, to match upstream defaults, of *not*
including HOME in env_keep.

More details are in this bug:
https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1556302

On Thu, May 16, 2019 at 5:10 AM Robie Basak  wrote:
>
> On Tue, May 14, 2019 at 01:12:56PM -0400, Dan Streetman wrote:
> > in Ubuntu, sudo retains the calling user's $HOME
> >
> > this is different from upstream sudo as well as all other UNIXes and
> > even the sudo documentation we provide.  Should we remove our custom
> > patch that adds this behavior?
>
> Does upstream have a position on this question, apart from our
> observation of their current default?
>
> For example: what if we changed it back, then someone persuaded upstream
> to flip the default? That would cause disruption to our users twice. Can
> we ensure, before reverting to their default, that upstream have no
> intention of changing it?
>
> 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

how sudo handles $HOME

[Dan Streetman]

in Ubuntu, sudo retains the calling user's $HOME

this is different from upstream sudo as well as all other UNIXes and
even the sudo documentation we provide.  Should we remove our custom
patch that adds this behavior?

for reference and more details on downsides of our current sudo behavior, see:
https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1556302

Note that I have kind-of hijacked the bug, as I believe the issue is
larger than the python-based example in that bug.

Also as I commented in that bug, I do not recommend changing the
behavior for existing releases.  But I do think we should change the
behavior starting in Eoan and future releases.

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

Re: libc6 == glibc ?

[Dan Streetman]

On Wed, Apr 10, 2019 at 10:41 AM Lenge  wrote:
>
> Hi ubuntu developers,
> why is the glibc named libc6, not libc5 or libc7 ? thanks.

https://en.wikipedia.org/wiki/GNU_C_Library#Fork_%22Linux_libc%22

>
> --
> lenge
> --
> 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: questions re: package qemu-system-sparc

[Dan Streetman]

On Tue, Apr 9, 2019 at 1:33 PM  wrote:
>
> [Emailing here because it's the published maintainer address for Ubuntu 
> package qemu-system-sparc.  Please redirect me if I should look elsewhere.]
>
> From what I've been able to find within Ubuntu 18.10, the latest available 
> version of qemu-system-sparc (and qemu in general) is 2.12.0 (Debian 
> 1:2.12+dfsg-3ubuntu8.6).
>
> However the upstream QEMU project released v3.0.0 on August 14 2018, thus I'd 
> hoped it would make it into Ubuntu 18.10.  Is the delay simply due to a lack 
> of resources?

the next ubuntu release, disco, has qemu 3.1 included:
$ rmadison -s disco -a source qemu
 qemu | 1:3.1+dfsg-2ubuntu3 | disco | source

It is scheduled for release soon:
https://wiki.ubuntu.com/DiscoDingo/ReleaseSchedule

>
> I've confirmed on my system that only the Partner repo isn't enabled.  Is 
> there a "testing" repo or similar that includes more recent versions of QEMU?
>
> Kind regards,
> --
> 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: anyone still use 'import-bug-from-debian'?

[Dan Streetman]

On Wed, Feb 13, 2019 at 10:04 AM Colin Watson  wrote:
>
> On Wed, Feb 13, 2019 at 08:40:39AM -0500, Dan Streetman wrote:
> > As far as I can tell, this hasn't been used by anyone in a long time,
> > or at least only a small number of times.
> >
> > Can anyone who uses it let me know?
>
> If it's helpful, there are 409 bugs in Launchpad whose description
> starts with the string "Imported from Debian bug"; the most recent one
> (https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1694425) was

Yeah, the most recent i found was
https://bugs.launchpad.net/ubuntu/+source/freevo/+bug/1699078
which is also from 2017.

I asked for comments from users since I'm overhauling u-d-t and
noticed it did not seem to be getting used by anyone.

> created on 2017-05-30.  It was quite heavily used up to 2015 or so; my
> general impression is that it's a slightly obscure tool so not widely
> used, but probably used enough to justify keeping it around.
>
> --
> Colin Watson   [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

anyone still use 'import-bug-from-debian'?

[Dan Streetman]

As far as I can tell, this hasn't been used by anyone in a long time,
or at least only a small number of times.

Can anyone who uses it let me know?

-- 
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: apt update behaves differently from apt-get update

[Dan Streetman]

On Fri, Jun 22, 2018 at 4:23 PM Nish Aravamudan
 wrote:
>
> On Fri, Jun 22, 2018 at 9:46 AM Lao Shaw  wrote:
>>
>> On my freshly installed ubuntu 18.06 my cron job use 'apt-get' as 'apt' is 
>> not recommended to be used in scripts. however, 'apt-get update' will keep 
>> back my packages while 'apt upgrade' will upgrade them, this is not expected.
>
>
> I think you have the wrong mailing list, but, `man apt` says:
>
>apt provides a high-level commandline interface for the package
>management system. It is intended as an end user interface and enables
>some options better suited for interactive usage by default compared to
>more specialized APT tools like apt-get(8) and apt-cache(8).
>
> This does not make me think that `apt` and `apt-get` are intended to have the 
> same behavior in all operations (given that some options are explicitly (well 
> the "some" is explicit, which actually are is not) enabled in `apt` only by 
> default.

$ man apt | grep -E -A 3 '^   upgrade'
   upgrade (apt-get(8))
   upgrade is used to install available upgrades of all
packages currently installed on the system from the sources configured
via sources.list(5). New packages will be installed if required to
satisfy dependencies, but existing packages will never be
   removed. If an upgrade for a package requires the remove of
an installed package the upgrade for this package isn't performed.

$ man apt-get | grep -E -A 4 '^   upgrade'
   upgrade
   upgrade is used to install the newest versions of all
packages currently installed on the system from the sources enumerated
in /etc/apt/sources.list. Packages currently installed with new
versions available are retrieved and upgraded; under no
   circumstances are currently installed packages removed, or
packages not already installed retrieved and installed. New versions
of currently installed packages that cannot be upgraded without
changing the install status of another package will be left at
   their current version. An update must be performed first so
that apt-get knows that new versions of packages are available.


as you said, notice the difference in behavior:
apt: "New packages will be installed if required to satisfy dependencies"
apt-get: "under no circumstances are ... packages not already
installed retrieved and installed"


>
> Thanks,
> Nish
> --
> 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: ebtables update breaks ubuntu updates on WSL

[Dan Streetman]

On Thu, May 31, 2018 at 8:47 AM, Balint Reczey
 wrote:
> Hi Dan,
>
> On Thu, May 31, 2018 at 12:39 PM, Dan Streetman
>  wrote:
>> This isn't a problem with ebtables, it's a problem in WSL.  Note in
>> the long WSL issues bug 1761 you linked to; there are reports of this
>> problem with packages other than just ebtables (for example, that bug
>> starts by complaining about mdadm).
>
> IMO there is a bug in communication.c in ebtables, since this is not a
> permission issue and it should be fixed to enable smooth upgrades in
> WSL.

IMO the "bug" is in ebtables.init and I've taken the lp bug and have a
test ppa; let's move the discussion to the bug if you disagree with my
patch.
https://bugs.launchpad.net/ubuntu/+source/ebtables/+bug/1774120

>
> The error ebtables gets in WSL is EPROTONOSUPPORT.
>
> Cheers,
> Balint
>
>>
>> On Wed, May 30, 2018 at 5:21 PM, Hayden Barnes  
>> wrote:
>>> List,
>>>
>>>
>>>
>>> The install script in the most recent update to ebtables is preventing
>>> Ubuntu users on WSL from updating.
>>>
>>>
>>>
>>> A temporary workaround exists.
>>>
>>>
>>>
>>> https://bugs.launchpad.net/ubuntu/+source/ebtables/+bug/1774120
>>>
>>>
>>>
>>> https://github.com/Microsoft/WSL/issues/1761
>>>
>>>
>>>
>>> https://www.reddit.com/r/bashonubuntuonwindows/comments/8n9h6o/unable_to_update_ebtables_with_apt/
>>>
>>>
>>>
>>>
>>>
>>> Thanks,
>>>
>>>
>>>
>>> Hayden
>>>
>>>
>>>
>>>
>>> --
>>> 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
>
>
>
> --
> Balint Reczey
> Ubuntu & Debian 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: ebtables update breaks ubuntu updates on WSL

[Dan Streetman]

This isn't a problem with ebtables, it's a problem in WSL.  Note in
the long WSL issues bug 1761 you linked to; there are reports of this
problem with packages other than just ebtables (for example, that bug
starts by complaining about mdadm).



On Wed, May 30, 2018 at 5:21 PM, Hayden Barnes  wrote:
> List,
>
>
>
> The install script in the most recent update to ebtables is preventing
> Ubuntu users on WSL from updating.
>
>
>
> A temporary workaround exists.
>
>
>
> https://bugs.launchpad.net/ubuntu/+source/ebtables/+bug/1774120
>
>
>
> https://github.com/Microsoft/WSL/issues/1761
>
>
>
> https://www.reddit.com/r/bashonubuntuonwindows/comments/8n9h6o/unable_to_update_ebtables_with_apt/
>
>
>
>
>
> Thanks,
>
>
>
> Hayden
>
>
>
>
> --
> 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: Suggestion: Native Linux Network Encryption (NLNE)

[Dan Streetman]

On Tue, Apr 17, 2018 at 1:05 PM, Jesse Cox  wrote:
> You guys don't know me. I'm not a developer of the OS but I think I have
> something which could benefit it in the long run.
>
> Here's the thing: I've been watching video after video about data security
> and encryption and why the average person refuses to adopt encryption
> standards. According to most of these videos, encryption is lacking in the
> world because it's complicated and no one wants to take the time to
> uncomplicate it. SSL was phased in because Netscape added it to their
> browser, forcing all the others to adopt it. I don't have the time to
> develop this project but I have an idea of how to implement a native
> encryption over insecure networks, for all Linux devices on the network. If
> this were a Linux router, it'd also be able to provide security despite
> having an open network.
>
> Here's the idea:
>
> This is all over an unsecured network (so Alice and Bob both have IP
> addresses -- let's say in the IPv4 spectrum for local wifi with an open
> network).
>
> Alice wants to talk to Bob and each of them have the networking software
> (virtual networking device) installed.
>
> The virtual device works by creating an IPv6 address for its client (so they
> both have one). The IPv6 is a hash of each client's public key.
>
> Let's say Alice's public key hash was 00:11:22:33:44:55:66
>
> And Bob's was 77:88:99:10:11:12
>
> Alice's virtual interface would broadcast a message over the IPv4 network
> asking for 77:88:99:10:11:12's public key (since the IP is a hash, the key
> must match and since Bob is the only one with the private key to match the
> hash, he's the only one who can communicate.

This is a bad assumption - a 'hash' is a reduction of a large value
down to a smaller value; it is incorrect that "Bob is the only one
with the private key to match the hash".  Whatever the hash function,
if the number of bits in the hash (IPv6 addr, 128 bits) is less than
the number of bits in the key (at least 2048, could be 4096 or even
higher) then there is no possible hash function that would hash each
key value into a unique hash value.  It's just not mathematically
possible.

Additionally, there are restrictions on what IPv6 value can be used.

Also, you seem to be confusing MAC addresses (XX:XX:XX:XX:XX:XX) with
IPv6 addresses (:::::::).

>
> Once Bob's interface sends Alice's interface his private key

Typically, you never give your private key away to anyone or any other
system.  It's not really "private" if you're giving it away, then it's
called a "shared" key.

> -- in response
> to the broadcast -- the interfaces can exchange AES keys and then
> communicate. The communications can't be hijacked at any point, just
> stopped.
>
> Why is this important?
>
> Linux as a system has a past of creating solutions which benefit their users
> well before any other system. As the push for encryption continues, history
> has shown us that users will not implement safety measures themselves. I
> think it'd be great for Ubuntu to set the standard for a Native Linux
> Network Encryption protocol, which starts on bootup with the system in
> question. This is just an idea but it'd be awesome and a major step forward
> in IT security.

I'm not saying this idea is not possible, it probably is possible at
the L2 layer to add some native encryption involving a per-endpoint
key exchange that encrypts each point-to-point L2 communication
separately.  However, I think that would be far, far more complex than
what you've outlined, but if I'm misunderstanding you then perhaps a
whitepaper with specific details on the entire process would help
explain your idea.

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