-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TestClear/Error_when_cache_dir_has_invalid_permissions is failing when building the deb #218
Comments
@denisonbarbosa I guess you can handle this :) |
At least one seems to be skippable: diff --git a/debian/control b/debian/control
index f808322..a9fb004 100644
--- a/debian/control
+++ b/debian/control
@@ -452,6 +452,11 @@ func TestClear(t *testing.T) {
require.NoError(t, os.Remove(c.DbPath()), "Setup: should be able to remove database file")
}
if tc.readOnlyDir {
+ currentUser, err := user.Current()
+ require.NoError(t, err)
+ if currentUser.Username == "root" {
+ t.Skip("Can't do permission checks as root")
+ }
testutils.MakeReadOnly(t, filepath.Dir(c.DbPath()))
}
|
The package builds normally for me and on launchpad as well. My question is: why are you building the deb as sudo? |
No sudo of course, but this is the error that you get when building it via In any case all the packages are run as |
That's the kind of thing that should be listed on Also, most of the tutorials and packaging documentation suggest using My point is that if we try to cover "all" of the possible tools/ways to build the package, we could end up with a lot of code only to support a specific occurrence, which is not great. In the team, we use |
I suggest you to document a bit better ;-) on packaging, but in short, you should never (unless for tiny packages or for frequent rebuilds), build a package in the local environment because that affects a lot the build process making the whole process flawed. To prevent this, and to make sure that a package has all the required components in depends & friends, one should build the package in a clean environment, and that's where
We documented it various years ago. And I do use gbp to generate the source packages too, but eventually it's |
This page has also some quick infos: https://debian-handbook.info/browse/stable/debian-packaging.html |
refactor quite a bit the `debian/*` code so that we are less dependent on our scripts, but instead we use debian tooling more. In particular: - Ensure that generated go files are properly created when bootstrapping the repo and removing them - Use `dh-cargo` tools more, reducing duplication - And when it's not possible, mimic its behavior more - Address various lintian warnings - Use install files to install the produced binaries - It has the benefit of fail if we miss something or if we're adding unexpected - Install the daemons in `/usr/libexec` instead of `/usr/sbin` (there's no need for them to be in `$PATH`) Closes: #218 UDENG-2342
Is there an existing issue for this?
Describe the issue
Steps to reproduce it
Ubuntu users: System information and logs
No response
Non Ubuntu users: System information and logs
No response
Relevant information
Eh... If we had #130 active we wouldn't have missed it... :)
Double check your logs
The text was updated successfully, but these errors were encountered: