Re: deb2snap transitional packages and channel tracking

[Steve Langasek]

Hi Julian,

I agree with everything you write.  The rationale for including the Ubuntu
release in the channel name for snaps installed via Ubuntu applies equally
whether that snap is preinstalled via an image, or pulled in via a
transitional deb; and whether the user is on an LTS release or not.

So I don't think they should be considering separate channel names only for
the LTS releases, but should instead be doing this for all releases.

Now, I think there may be a practical issue here; as I recall, trying to
install from a closed channel will automatically fall back to latest/stable,
but the maas team want to put users on 2.7/stable.  That probably needs to
be a conversation with the Snap Store Team; but barring a solution for this,
I don't think it's appropriate to force the maas deb to put people on
latest/stable where that's not the MAAS Team's intent, and it's also not
particularly friendly to make the MAAS Team actively manage
2.7/stable/ubuntu-$release channels across all supported releases and require
that they be kept in sync with 2.7/stable.

If the MAAS Team /are/ willing to manage publication on their side so that
2.7/stable/ubuntu-20.10, etc. are all kept in sync with 2.7/stable, then
that would be the best technical outcome for our users.  But if this isn't
pratical, then until a store-side solution is available, it is better to
have the deb installing 2.7/stable instead of tracking
2.7/stable/ubuntu-20.10 and having this fall through to latest/stable.

On Fri, May 08, 2020 at 03:59:59PM +0200, Julian Andres Klode wrote:
> I've been reviewing some of ack's changes for the maas deb2snap
> transitional package, and in the latest merge request
> 
> - 
> https://code.launchpad.net/~ack/ubuntu/+source/maas/+git/maas/+merge/383411
> -
> 
> a topic came up that I don't think we've discussed before.
> 
> Currently, the maas deb installs maas 2.7/stable/ubuntu-$release
> (or other versions of maas instead of 2.7). They'd like to add a
> fallback that if the /ubuntu-$release channel is not there, it
> would install 2.7/stable instead, and then maybe only have the
> /ubuntu-$release channels for LTS releases.
> 
> Now, I don't think this makes a lot of sense. I'd argue that
> the same policies as for seeded snaps should also apply to
> deb2snap transitions, as the rationale is the same - we can,
> if necessary, roll out fixes specific to an Ubuntu release.
> 
> It also creates less confusion if people install the Ubuntu devel
> release while no such channel exists yet - people who install early
> in the 22.04 cycle would track 2.7/stable, people who install
> late would get 2.7/stable/ubuntu-22.04.
> 
> 
> So I don't think we currently have a progress for deb2snap transitions
> where the snap is not seeded. I think it should be the same as
> for seeded snaps:
> 
> * deb2snap target snaps should always track /ubuntu-$release channels
> * deb2snap target snaps should be notified to create such channels
>   on archive opening
> 
> This ensures that people get a consistent experience for snaps
> they get pre-installed, and snaps they get upgraded from debs,
> or if they install a new deb that installs a snap.

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


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

deb2snap transitional packages and channel tracking

[Julian Andres Klode]

I've been reviewing some of ack's changes for the maas deb2snap
transitional package, and in the latest merge request

- 
https://code.launchpad.net/~ack/ubuntu/+source/maas/+git/maas/+merge/383411
-

a topic came up that I don't think we've discussed before.

Currently, the maas deb installs maas 2.7/stable/ubuntu-$release
(or other versions of maas instead of 2.7). They'd like to add a
fallback that if the /ubuntu-$release channel is not there, it
would install 2.7/stable instead, and then maybe only have the
/ubuntu-$release channels for LTS releases.

Now, I don't think this makes a lot of sense. I'd argue that
the same policies as for seeded snaps should also apply to
deb2snap transitions, as the rationale is the same - we can,
if necessary, roll out fixes specific to an Ubuntu release.

It also creates less confusion if people install the Ubuntu devel
release while no such channel exists yet - people who install early
in the 22.04 cycle would track 2.7/stable, people who install
late would get 2.7/stable/ubuntu-22.04.


So I don't think we currently have a progress for deb2snap transitions
where the snap is not seeded. I think it should be the same as
for seeded snaps:

* deb2snap target snaps should always track /ubuntu-$release channels
* deb2snap target snaps should be notified to create such channels
  on archive opening

This ensures that people get a consistent experience for snaps
they get pre-installed, and snaps they get upgraded from debs,
or if they install a new deb that installs a snap.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

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

Re: Trademark concerns with Chef/Cinc package included in Debian and Ubuntu

[Lucas Kanashiro]

Hi Rafael,

I reported this issue yesterday here:

https://bugs.launchpad.net/chef/+bug/1877462

Steve reviewed it and marked it as Invalid.

On 08/05/2020 10:14, Rafael David Tinoco wrote:
> Forwarding to Ubuntu Devel Mailing list for broader audience.
>
> Should I just open a [RM] bug for all Ubuntu versions ? Any thoughts ?

BTW just Focal would be affected.

Cheers!



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

Re: Trademark concerns with Chef/Cinc package included in Debian and Ubuntu

[Rafael David Tinoco]

Forwarding to Ubuntu Devel Mailing list for broader audience.

Should I just open a [RM] bug for all Ubuntu versions ? Any thoughts ?

-rafaeldtinoco

On 07/05/2020 19:01, Lance Albertson wrote:
> I think removing it from Debian is the safe way to go currently. If
> you want assistance with how we build Cinc and how it could be adapted
> for Debian let me know. Also if there are any changes we can make on
> our end to make it easier.
>
> Thanks-
>
> On Thu, May 7, 2020 at 2:14 PM Antonio Terceiro  > wrote:
>
> On Thu, May 07, 2020 at 03:32:10PM -0400, benny Vasquez wrote:
> > Thanks, Lance!
> >
> > As he laid out, this packaged shipped as-is is a pretty serious
> violation
> > of our trademarks, and we'd like to see it addressed as soon as
> humanly
> > possible.
> >
> > On Thu, May 7, 2020 at 2:40 PM Lance Albertson  > wrote:
> >
> > > All,
> > >
> > > I'm a member of the Cinc Project [1] which rebuilds and
> rebrands various
> > > Chef projects to comply with Chef Trademark Policy [2]. We
> have worked
> > > closely with Chef to ensure Cinc Client complies with this policy.
> > >
> > > A member of our community notified us today that it appears
> that Ubuntu
> > > [3] and Debian [4] are both including a package called "chef"
> which seems
> > > to pull in the Cinc source code but doesn't fully comply with
> the Chef
> > > Trademark Policy. We are concerned that this use of the Cinc
> Client in the
> > > manner it's currently presented will create an issue for us
> and you in the
> > > future unless this gets resolved quickly.
> > >
> > > Specifically, we are concerned with the following:
> > >
> > > 1. The package name should be cinc and not chef as Chef is
> trademarked and
> > > also causes users to think they are installing Chef when they are
> > > installing Cinc
> > > 2. The package should have proper attributions to include the
> Cinc Project
> > > including pointing any issues related to the package to our
> issue page, and
> > > not Chef
> > > 2. Running "chef-client" (or other similar commands) does not
> tell the
> > > user that it's actually using Cinc Client as our package does
> properly
> > > 3. All of the trademark renaming we did in our Cinc Client
> distribution
> > > seems to have been removed and retains all of the Chef related
> paths (i.e.
> > > /etc/chef when it should be /etc/cinc). This will cause
> confusion for users
> > > who are expecting Cinc.
> > >
> > > We would like to work with the Debian/Ubuntu maintainers to
> ensure you're
> > > following compliance and also ensuring our distribution works
> well on
> > > Debian/Ubuntu. However we also want to ensure you don't get
> into any legal
> > > trouble with Chef. I am sure most of these changes weren't done
> > > intentionally and was a mistake.
> > >
> > > Feel free to reach out to us via the #community-distros
> channel on the
> > > Chef Community Slack, or you can reach me directly via IRC on
> Freenode as
> > > "Ramereth".  I've also cc'd Benny Vasquez who is a community
> manager at
> > > Chef who can answer any questions relating to this and provide any
> > > additional feedback.
> > >
> > > Thanks!
> > >
> > > [1] https://cinc.sh/
> > > [2] https://www.chef.io/trademark-policy/
> > > [3] https://packages.ubuntu.com/focal/chef
> > > [4] https://packages.debian.org/sid/chef
>
> I am inclined to just remove chef from Debian as a way of fixing this.
>
> Maybe I will package cinc from scratch. That would be easier if there
> were proper source releases.
>

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