Re: GNOME Games source name

[Sébastien Wilmet]

On Fri, Jun 03, 2016 at 10:50:04AM -0500, Michael Catanzaro wrote:
> I talked with Adrien and he doesn't want to change the name... so GNOME
> Games it will continue to be. So there's probably not much point to
> continued discussion here.
> 
> I realize this is inconvenient for Debian and other distros that might
> need to pick a different source package name, but the original upstream
> gnome-games module was removed in GNOME 3.8, so it's been three years
> from an upstream perspective and we're fine with reusing the name at
> this point.

Then the gnome-games project can recommend to distros to use another
name for the package, so that it has more chances that it'll be the same
name on all distros.

--
Sébastien
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Enabling builddir != srcdir by default in jhbuild

[Juan A. Suarez Romero]

On Fri, 2016-06-03 at 12:31 +0100, Emmanuele Bassi wrote:
> > What's the proper fix for this then?
> 
> In general, everything that modifies the Git repository or the
> autotools files, like `git submodule update` or `gtkdocize` or
> `intltoolize` will need to be called inside the source directory;
> this
> means switching to $srcdir, calling those tools, and then switch back
> to the build directory.


You could also use "git -C $srcdir ".


J.A.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME Games source name

[Michael Catanzaro]

On Thu, 2016-06-02 at 07:05 -0500, Michael Catanzaro wrote:
> Since this app has not yet been packaged by distros, I think now
> would
> be a great time to change the name (GNOME Video Games is my
> preference). A name change would be painful down the road, but if we
> do
> it now it's not so bad. We discussed more name possibilities a couple
> years ago [1].
> 
> But it's ultimately Adrian's choice. Distros can surely get by
> regardless.
> 
> Michael

Hi,

I talked with Adrien and he doesn't want to change the name... so GNOME
Games it will continue to be. So there's probably not much point to
continued discussion here.

I realize this is inconvenient for Debian and other distros that might
need to pick a different source package name, but the original upstream
gnome-games module was removed in GNOME 3.8, so it's been three years
from an upstream perspective and we're fine with reusing the name at
this point.

Michael
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Continuous Builds in GNOME

[philip . chimento]

On Fri, Jun 3, 2016, 01:42 Emmanuele Bassi  wrote:

>
> Right now, the easiest and cheapest option would literally be moving
> the GNOME development infrastructure wholesale to GitHub, put
> everything under Travis CI, and keep a separate machine somewhere that
> cranks out GNOME Continuous images from the GitHub repositories. For
> reasons that you may guess, this is not going to be a very good move.
> Any other option involves replicating that set up on gnome.org
> infrastructure, with all the issues that it entails.
>

We already have mirrors of all the Gnome repositories on GitHub, and I
believe you could run Travis CI off of those without shifting the entire
primary infrastructure to GitHub. Travis CI isn't free-as-in-speech, but as
far as I know there is no lock-in. Maybe having such a setup as a temporary
measure would 1) visibly demonstrate to module maintainers why it's useful
and necessary, and therefore help to get people out of the "it builds on my
machine" mindset; and 2) inspire people to replicate it on Gnome
infrastructure out of free components. That task would probably seem less
daunting if there was a familiar example to follow.

Travis will hardly be ideal either though, because I believe we'd have a
hard time getting dependencies of our bleeding edge modules onto their
Ubuntu 12.04 and 14.04 VMs...

Regards,
Philip C

>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Continuous Builds in GNOME

[Sriram Ramkrishna]

On Fri, Jun 3, 2016 at 1:42 AM Emmanuele Bassi  wrote:

> Hi Sri;
>
> On 3 June 2016 at 02:53, Sriram Ramkrishna  wrote:
> > I found this discussion really fascinating and so I wanted to continue
> it,
> > separately from Emmanuele's thread so that issue is resolved without
> > bifurcating the discussion.
> >
> > My thoughts are that we really shouldn't be looking at something and say
> > 'well, we can't do it we don't have the resources' especially when there
> is
> > a clear return on investment.  I think this would be an interesting
> > challenge and we should find a way to figure out how we can attract the
> > talent, machines and money to do this.  After all, we have a foundation
> > dedicated to supporting the development of GNOME.
>
> Can the Foundation hire a full time "build team" that:
>
>  * keeps the build machines running
>  * keeps the build running
>  * works on the necessary tooling to integrate our Git repositories
> activity with our mailing list, our bug tracking system, and possibly
> our IRC channels
>

I don't know, right now, probably not.  But we could attract some devops
talent, and help support the initiatives and Andrea Veri and Patrick
Uiterwijk have been doing to attractive them.  We only a part time person
for the moment and even that has given us a significant benefit.

But as you allude to, even with the above we have a social problem, so
before we can even do that we need to figure out how to get maintainers to
participate into the build system.  In this day and age, most developers
accept the fact of using a try server and not merging code that doesn't
build.


>
> The current situation can barely run on volunteers time, and I think
> it's time to be pretty clear on what our requirements are — instead of
> architecture astronauting our way out.
>

Sure.


>
>
> Right now, the easiest and cheapest option would literally be moving
> the GNOME development infrastructure wholesale to GitHub, put
> everything under Travis CI, and keep a separate machine somewhere that
> cranks out GNOME Continuous images from the GitHub repositories. For
> reasons that you may guess, this is not going to be a very good move.
> Any other option involves replicating that set up on gnome.org
> infrastructure, with all the issues that it entails.
>

Yes, but it highlights the value something like GitHub provides.  What
about GitLab?  (BTW I'm not advocating we move, just looking to see
alternatives)  GitLab while open source, does not seem to open source its
CI work that I can tell.  Still, maybe a deal can be made..


>
> Incidentally, if you find somebody like that, good luck not getting
> them poached by companies that want the exact same thing, and are
> likely to pay more than the GNOME Foundation for it.
>
>
Actually, I was going to use this argument to find me talented, but out of
work systems administrators who for whatever reason is not able to find a
job.  I know one such right now, and I've worked with him for 20 years.  It
is completely within his skill set. If we can find someone who can actually
implement it then we have at least some chance.



>
> Still, people consider Continuous somebody else's problem; if it
> "breaks on Continuous" but not on a maintainer machine, then who
> cares?
>

Then we should change where Continuous fits in the scheme of things by
asking the release team to have weekly builds from Continuous.

We should consider everything on the table.



>
> Even if we magically got the resources (build machines, at least one
> person working on the infrastructure side, volunteer work to improve
> the tooling), the attitude of "my module is my fiefdom, if a build
> breaks *you* fix it" has to change. GNOME has long since become an
> interconnected, complex system, and it requires a level of oversight
> that does not map with "a loosely coupled set of components", with
> each one of them that may or may not build; may or may not pass tests;
> may or may not break other components; may or may not lead to a
> bootable, usable system.
>

Well, we've done a lot of social changes, bringing in designers working
with developers, all firsts in a Free Software project.  It is clear we can
make social changes when we need to.

Since 2011, we've already started to think of ourselves as a product, and
so the idea that some people think we are still a loosely coupled set of
components is old way thinking and they need to 'git pull' on their
thinking.


>
> So, more than a *technical* issue (as usual), this is a *social*
> issue. People have to care about this stuff — and not just a couple of
> people getting Continuous running.
>
>
Well, I think to expand on that, all of us need to think about the big
picture.  We have an entire foundation set up to drive development.  But I
think there is a disconnect between development (development, translation,
and documentation) and the foundation/money/engagement.  People don't
realize that everything is 

Re: GNOME Games source name

[Bastien Nocera]

On Fri, 2016-06-03 at 15:53 +0200, Sébastien Wilmet wrote:
> On Thu, Jun 02, 2016 at 03:10:59PM +0200, Bastien Nocera wrote:
> > Yet this is what you're doing. If you want an application to be
> > renamed, you'd better make sure that you can actually come up with
> > a
> > good name, and argue why it is an insurmountable problem to call
> > the
> > package "gnome-games-app" or similar in your distribution.
> 
> gnome-games-center ? Like gnome-control-center.
> 
> Anyway, the plugins of gnome-games will maybe be tricky to package.
> Isn't a Flatpak sufficient? The purpose of Flatpak is to avoid all
> the
> duplicated work of packaging in all the distros. I have always seen
> that
> as a big waste of time. For new apps, does it really make sense to
> package them in the traditional manner?

Again, that's not relevant to the discussion about why the "gnome-
games" tarball name is a problem for distributions.

The flatpak name is "org.gnome.Games". I doubt it conflicts with
anything.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME Games source name

[Sébastien Wilmet]

On Thu, Jun 02, 2016 at 03:10:59PM +0200, Bastien Nocera wrote:
> Yet this is what you're doing. If you want an application to be
> renamed, you'd better make sure that you can actually come up with a
> good name, and argue why it is an insurmountable problem to call the
> package "gnome-games-app" or similar in your distribution.

gnome-games-center ? Like gnome-control-center.

Anyway, the plugins of gnome-games will maybe be tricky to package.
Isn't a Flatpak sufficient? The purpose of Flatpak is to avoid all the
duplicated work of packaging in all the distros. I have always seen that
as a big waste of time. For new apps, does it really make sense to
package them in the traditional manner?

--
Sébastien
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Continuous Builds in GNOME

[Michael Catanzaro]

On Fri, 2016-06-03 at 09:42 +0100, Emmanuele Bassi wrote:
> Even if we magically got the resources (build machines, at least one
> person working on the infrastructure side, volunteer work to improve
> the tooling), the attitude of "my module is my fiefdom, if a build
> breaks *you* fix it" has to change. GNOME has long since become an
> interconnected, complex system, and it requires a level of oversight
> that does not map with "a loosely coupled set of components", with
> each one of them that may or may not build; may or may not pass
> tests;
> may or may not break other components; may or may not lead to a
> bootable, usable system.

Based on the last time we discussed this, I'm pretty sure this view is
passionately-held by a very small minority of contributors. Yes it's a
social issue, but also a technical one with bearing on our ability to
onboard new contributors and the productivity of existing contributors.
I support a policy that all contributors may revert a patch on master
if it breaks Continuous, and I suspect the rest of release team would
as well, as we're tired of dealing with jhbuild issues on release day.
master should always be buildable.

I expect module maintainers to be understanding when reverts happen.
It's not the end of the world; you can land your change again as soon
as you figure out why it was broken. We can all live with a few revert
commits in our git history. Your module can still be your fiefdom...
just so long as it's still building with the rest of GNOME.

I would also like us to stop tagging modules in Continuous in general,
instead revert commits that introduce build breakage in the modules
themselves, and save tagging for very rare cases where reverts are not
appropriate. Of course, sometimes we may need a transition in which
master of some module is broken for a brief period while somebody is
actively working on fixing it (in a matter of hours, not days). Such
issues are reasonable if they're rare. But in general, everyone should
feel empowered to keep our modules building.

Michael
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME Games source name

[Bastien Nocera]

On Thu, 2016-06-02 at 20:43 +0200, Sébastien Wilmet wrote:
> On Thu, Jun 02, 2016 at 03:10:59PM +0200, Bastien Nocera wrote:
> > If you want an application to be
> > renamed, you'd better make sure that you can actually come up with
> > a
> > good name, and argue why it is an insurmountable problem to call
> > the
> > package "gnome-games-app" or similar in your distribution.
> > 
> > gnome-games has been called gnome-games for 2 years. It uses the
> > gnome-
> > games list for communication, it uses the gnome-games bugzilla, it
> > uses
> > the gnome-games git repo.
> 
> gnome-games is not hosted on gnome.org since a long time, the project
> has moved from GitHub to gnome.org recently. I already talked to
> Adrien
> about the naming problem well before it was hosted on gnome.org.
> 
> Is the gnome-games mailing list also for the other games in GNOME? If
> not, the name is misleading. The same for the bugzilla product. Users
> will start filing bugs on gnome-games because, hey, that's what they
> installed on their system.
> 
> Personally, when I develop a new software, I make sure the name that
> I
> choose isn't yet used or at least not widely used in the same domain.
> To
> have good results in a search engine, and find it easily in a package
> manager. That's just common sense but I'm sure you can find it
> written
> somewhere in a list of good practices when writing free software. For
> example:
> http://producingoss.com/en/getting-started.html#choosing-a-name
> 
> which is a recommended reading from the GNOME programming guidelines:
> https://developer.gnome.org/programming-guidelines/stable/additional-
> materials.html.en
> 
> So in the first link you can read:
> 
>   “Is not the same as some other project's name, and does not
> infringe on any trademarks. This is just good manners, as well as
> good
> legal sense. You don't want to create identity confusion. It's hard
> enough to keep track of everything that's available on the Net
> already,
> without different things having the same name.”
> 
> (side note, it's a bit ironic to see gnome.org as an example a bit
> below
> on the same page)

This is a discussion about why the use of the gnome-games name might or
might not be legitimate. That isn't an answer to the questions I asked
however.

> Btw Michael Catanzaro is a member of the release team. In GNOME
> module
> maintainers have a lot of freedom, but maybe it is a good idea to
> know
> the opinion of the release team, since it's the team responsible for
> what GNOME ships. gnome-games (the new one) is not part of GNOME core
> though.

Would be great if you, or somebody else, could answer my questions.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Enabling builddir != srcdir by default in jhbuild

[Emmanuele Bassi]

Hi Bastien;

On 3 June 2016 at 12:11, Bastien Nocera  wrote:
> On Thu, 2016-06-02 at 23:50 +0100, Emmanuele Bassi wrote:
>> [ Picking this up again ]
>>
>> As a last resource, we can mark modules that do not support non-
>> srcdir
>> builds in the various modulesets, but I'd rather avoid it as it
>> defeats the purpose.
>
> Looks like this is uncovering more bugs.

Yes; right now I'm blocked on getting a WebKit build going because of
dependencies.

> $ jhbuild buildone -afn gnome-documents
> *** Configuring gnome-documents *** [1/1]
> /home/hadess/Projects/jhbuild/gnome-documents/autogen.sh --prefix
> /home/hadess/Projects/gnome-install --disable-Werror  --enable-getting-
> started
> /usr/bin/gnome-autogen.sh
> fatal: Not a git repository (or any parent up to mount point /home)
> Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not
> set).
> 
>
> The autogen.sh tries to run:
> git submodule update --init --recursive
>
> Which might, or might not be a good idea. In any case, that won't work
> if cwd isn't the git repo.
>
> What's the proper fix for this then?

In general, everything that modifies the Git repository or the
autotools files, like `git submodule update` or `gtkdocize` or
`intltoolize` will need to be called inside the source directory; this
means switching to $srcdir, calling those tools, and then switch back
to the build directory.

In this case, I just fixed gnome-documents with this commit:

  
https://git.gnome.org/browse/gnome-documents/commit/?id=7668513171a0e9812a3fc2fc396e8b8d960e9072

The main change is that jhbuild runs the autogen script from within
the build directory, instead of running it into the source directory
and then running the configure script from the build directory. This
means that the autogen script needs to cope with this case. Most of
the autogen scripts do, and gnome-autogen.sh does as well, assuming
the $srcdir variable is set appropriately.

The rest of the build failures I've seen mostly deal with:

 * Vala
 * the introspection scanner not being given the appropriate include paths
 * the assumption that you run a full build in the srcdir before
running in a separate builddir, which is fair (even if not really
appropriate) for `make distcheck`, but it obviously fails for
non-srcdir builds

Ciao,
 Emmanuele.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Enabling builddir != srcdir by default in jhbuild

[Bastien Nocera]

On Thu, 2016-06-02 at 23:50 +0100, Emmanuele Bassi wrote:
> [ Picking this up again ]
> 
> I've been spending the last couple of days fixing modules on
> git.gnome.org (you may have noticed a commit or two from me on your
> modules fixing builddir != srcdir issues); submitting bugs/patches to
> modules that are hosted elsewhere; and disabling non-srcdir builds
> directly in the jhbuild modulesets. I'm fairly confident that all
> remaining issues are now limited to modules that are in gnome-apps or
> gnome-world, but I haven't tested things like all the C++ language
> bindings modules.
> 
> If you maintain a module listed in jhbuild, *please* update your
> jhbuild local repository and try build your module with the new
> buildroot setting enabled. If your module fails to build, fixing it
> would also be appreciated — as it would spare you and everybody else
> time and effort; alternatively, you can poke me on IRC, and I'll
> either fix it for you, or help you out in fixing it.
> 
> As a last resource, we can mark modules that do not support non-
> srcdir
> builds in the various modulesets, but I'd rather avoid it as it
> defeats the purpose.

Looks like this is uncovering more bugs.
$ jhbuild buildone -afn gnome-documents
*** Configuring gnome-documents *** [1/1]
/home/hadess/Projects/jhbuild/gnome-documents/autogen.sh --prefix
/home/hadess/Projects/gnome-install --disable-Werror  --enable-getting-
started 
/usr/bin/gnome-autogen.sh
fatal: Not a git repository (or any parent up to mount point /home)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not
set).


The autogen.sh tries to run:
git submodule update --init --recursive

Which might, or might not be a good idea. In any case, that won't work
if cwd isn't the git repo.

What's the proper fix for this then?

Cheers
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Continuous Builds in GNOME

[Sebastian Geiger (Lanoxx)]

Hi Emanuelle,

I just wanted to pitch into this discussion and say thanks to you (and 
everyone else working on this) for putting all the effort into fixing 
build issues and improving continuous integration.


I have been a developer for different gnome components for a while, but 
I am not such a frequent contributor that I know all the internals of 
most core components. So when a module breaks during a jhbuild, then I 
am often quite lost and need a few hours of google, asking people at 
#gtk or #gnome as well as trial and error.


Most of the time I just want to "quickly get a fairly recent build" and 
then "write a small patch" to fix something in one of the gnome modules. 
When that happens I may be able to set aside a few hours or half a day 
but not a whole week. However most times this half day is wasted 
battling with jhbuild and trying to get a working environment that not 
only builds glib but which actually comes as far as to build the module 
for which I wanted to write a patch in the first place. When I have 
already spend 4 hours and jhbuild is just building module 20 out of 90, 
and breaking on some unresolvable dependency, missing library, some 
obscure configure or make error or what ever, then this is usually the 
point were I just go and do something else.


So again, all your effort its highly appreciated.

I really hope that at some point in the future its possible to just type 
`jhbuild build` then go away to work on something else when then come 
back to find the build finished and login to the ready jhbuild session. 
If on top of that this would work not only on the most recent fedora 
"from last week" or so, but on the most recent Ubuntu _LTS_ or Debian 
_stable_, then that would be really awesome. And it would mean that I 
could spend more time testing gnome modules, fixing bugs and help to 
improve gnome rather then spending days trying to get all modules building.


Thanks and Cheers
Sebastian

On 03/06/16 10:42, Emmanuele Bassi wrote:

Still, people consider Continuous somebody else's problem; if it
"breaks on Continuous" but not on a maintainer machine, then who
cares?

Even if we magically got the resources (build machines, at least one
person working on the infrastructure side, volunteer work to improve
the tooling), the attitude of "my module is my fiefdom, if a build
breaks*you*  fix it" has to change.


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Continuous Builds in GNOME

[Emmanuele Bassi]

Hi Sri;

On 3 June 2016 at 02:53, Sriram Ramkrishna  wrote:
> I found this discussion really fascinating and so I wanted to continue it,
> separately from Emmanuele's thread so that issue is resolved without
> bifurcating the discussion.
>
> My thoughts are that we really shouldn't be looking at something and say
> 'well, we can't do it we don't have the resources' especially when there is
> a clear return on investment.  I think this would be an interesting
> challenge and we should find a way to figure out how we can attract the
> talent, machines and money to do this.  After all, we have a foundation
> dedicated to supporting the development of GNOME.

Can the Foundation hire a full time "build team" that:

 * keeps the build machines running
 * keeps the build running
 * works on the necessary tooling to integrate our Git repositories
activity with our mailing list, our bug tracking system, and possibly
our IRC channels

The current situation can barely run on volunteers time, and I think
it's time to be pretty clear on what our requirements are — instead of
architecture astronauting our way out.

We don't need machines; those are "easy" to get. We need actual people
that would fit the bill of a "devops" team; we need people that can
install and maintain a complex build system; that set up a Continuous
Integration process on top of our existing Continuous Delivery one;
and that can fill in the blank spots on the map between "this branch
on this module failed to build" and "this is breaking the whole GNOME
please fix it".

Right now, the easiest and cheapest option would literally be moving
the GNOME development infrastructure wholesale to GitHub, put
everything under Travis CI, and keep a separate machine somewhere that
cranks out GNOME Continuous images from the GitHub repositories. For
reasons that you may guess, this is not going to be a very good move.
Any other option involves replicating that set up on gnome.org
infrastructure, with all the issues that it entails.

Incidentally, if you find somebody like that, good luck not getting
them poached by companies that want the exact same thing, and are
likely to pay more than the GNOME Foundation for it.

> We have an amazing infrastructure that we can attract possible very smart
> people of whatever age to come and work on for the betterment of GNOME and
> of course their own careers.

Colin Walters presented Continuous to the GNOME community in 2012 —
and it was already cranking out GNOME builds. Apart from a flurry of
activity in the beginning, I have not seen much interest being
attracted to the actual tools; for a long while, people didn't even
care much about the builds — and to be fair, why would they? It works
on *their* machine and maybe they can even release tarballs every once
in a while, and if it breaks patches welcome, right? Well, patches
started to arrive, and at the end we got a much better experience for
newcomers, with jhbuild not constantly breaking.

Still, people consider Continuous somebody else's problem; if it
"breaks on Continuous" but not on a maintainer machine, then who
cares?

Even if we magically got the resources (build machines, at least one
person working on the infrastructure side, volunteer work to improve
the tooling), the attitude of "my module is my fiefdom, if a build
breaks *you* fix it" has to change. GNOME has long since become an
interconnected, complex system, and it requires a level of oversight
that does not map with "a loosely coupled set of components", with
each one of them that may or may not build; may or may not pass tests;
may or may not break other components; may or may not lead to a
bootable, usable system.

So, more than a *technical* issue (as usual), this is a *social*
issue. People have to care about this stuff — and not just a couple of
people getting Continuous running.

> I just hate when we say we don't have resources when we can't quantify what
> we have and we aren't quantifying what we need.  I mean, yes, it is
> difficult and hard right now, and so we need to make strategic plans to fix
> it especially if it is a man power problem.  Our development, our
> engagement, the board, everything is connected and so we need to look at it
> from all angles.
>
> I really love the ideas of try servers, and you know they have this some how
> in github, and man, we should try to find clever means to do the same thing.

Sometimes there are no "clever" options, just the old dumb ones.

Ciao,
 Emmanuele.

> -- Forwarded message -
> From: Emmanuele Bassi 
> Date: Tue, May 31, 2016 at 9:51 AM
> Subject: Re: Enabling builddir != srcdir by default in jhbuild
> To: Michael Catanzaro 
> Cc: Desktop Development List 
>
>
> Hi;
>
> I already pushed the default change to master, as that will only
> affect new clones or updates. I'm also building locally the default
> gnome moduleset — but I can safely