Skip to content
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.

Sign up for GitHub

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

[fetch_binary_drivers] new [fetch_drivers] package #27

Merged
merged 11 commits into from
Feb 13, 2019
Merged

[fetch_binary_drivers] new [fetch_drivers] package #27

Show file tree
Hide file tree
Changes from 10 commits
Commits
Show all changes
11 commits
Select commit Hold shift + click to select a range
f2fab5b
[fetch_binary_drivers] new [fetch_drivers] package
moriarty Feb 2, 2019
8e144f9
System config debian components for ROS Melodic
erelson Feb 1, 2019
32f18f8
[fetch_system_config] fix README
moriarty Feb 2, 2019
5f022ca
Fixup system config debian
erelson Feb 4, 2019
529db79
Fixup .gitignore
erelson Feb 4, 2019
ead867e
[fetch_drivers] add more dependencies
moriarty Feb 5, 2019
b144529
Ensure robots power off safely when instructed to
erelson Feb 7, 2019
c5ee991
Update .gitignore
erelson Feb 7, 2019
d305db0
Fix typo in .gitignore
erelson Feb 9, 2019
4432ece
Update wifi power management disabling
erelson Feb 10, 2019
68d33fa
Copy updates to freight post-install script
erelson Feb 12, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 14 additions & 0 deletions .gitignore
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,14 @@
build
*.tar.gz
*.so

# system config; these are all files generated by dpkg-buildpackage
*.deb
*.debhelper
*.substvars
*.log
*.dsc
*.changes
fetch-melodic-config
freight-melodic-config
files
erelson marked this conversation as resolved.
Show resolved Hide resolved
98 changes: 98 additions & 0 deletions fetch_binary_drivers/CMakeLists.txt
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,98 @@
cmake_minimum_required(VERSION 3.5)
project(fetch_drivers)

###
#
# This is the public version of fetch_drivers.
#
# This is a binary only release of our dirvers and firmware.
# The drivers and firmware have been compiled for our research robots, inside of Docker containers on our TeamCity build servers.
#
# The resulting output of that build job a tar.gz, where the build job should only copy in what is required for the research robots.
# This public repository, just pulls in that tar.gz and extracts installs it into ROS/catkin paths.
##

find_package(catkin REQUIRED
COMPONENTS
mk
)

## System dependencies are found with CMake's conventions
find_package(Boost REQUIRED
COMPONENTS
chrono
filesystem
program_options
regex
system
thread
)
find_package(CURL REQUIRED)
find_package(PythonLibs REQUIRED)
find_package(yaml-cpp REQUIRED)

add_custom_target(
binary_driver ALL
COMMAND cmake -E chdir ${PROJECT_SOURCE_DIR} $(MAKE) -f Makefile.tarball
COMMAND cmake -E make_directory ${CATKIN_DEVEL_PREFIX}/${CATKIN_GLOBAL_LIB_DESTINATION}/${PROJECT_NAME}
COMMAND cmake -E copy_if_different ${PROJECT_SOURCE_DIR}/build/output/lib/libfetch_drivers.so ${CATKIN_DEVEL_PREFIX}/${CATKIN_GLOBAL_LIB_DESTINATION}/libfetch_drivers.so
COMMAND cmake -E copy_if_different ${PROJECT_SOURCE_DIR}/build/output/lib/libfetch_drivers_odva.so ${CATKIN_DEVEL_PREFIX}/${CATKIN_GLOBAL_LIB_DESTINATION}/libfetch_drivers_odva.so
COMMAND cmake -E copy ${PROJECT_SOURCE_DIR}/build/output/lib/${PROJECT_NAME}/* ${CATKIN_DEVEL_PREFIX}/${CATKIN_GLOBAL_LIB_DESTINATION}/${PROJECT_NAME}/
COMMAND cmake -E make_directory ${CATKIN_DEVEL_PREFIX}/${CATKIN_GLOBAL_SHARE_DESTINATION}/${PROJECT_NAME}
COMMAND cmake -E copy_if_different ${PROJECT_SOURCE_DIR}/build/output/share/${PROJECT_NAME}/firmware.tar.gz ${CATKIN_DEVEL_PREFIX}/${CATKIN_GLOBAL_SHARE_DESTINATION}/${PROJECT_NAME}/
)

###################################
## catkin specific configuration ##
###################################
## The catkin_package macro generates cmake config files for your package
## Declare things to be passed to dependent projects
## LIBRARIES: libraries you create in this project that dependent projects also need
## CATKIN_DEPENDS: catkin_packages dependent projects also need
## DEPENDS: system dependencies of this project that dependent projects also need
catkin_package(
LIBRARIES fetch_drivers
CATKIN_DEPENDS
actionlib
actionlib_msgs
diagnostic_msgs
fetch_driver_msgs
fetch_auto_dock_msgs
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can't find a reference in the drivers to auto_dock

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cjds it might be stripped out of the research platform drivers.

amoriarty at SW44 in ~/ros/melodic/fetch-private/src/fetch_drivers on master
$ grep -rl auto_dock_msgs .
./CMakeLists.txt
./include/fetch_drivers/logpro/client.h
./package.xml
./src/logpro_client.cpp

nav_msgs
power_msgs
robot_calibration_msgs
roscpp
sensor_msgs
DEPENDS
Boost
CURL
PYTHON
YAML_CPP
)

###########
## Build ##
###########

#############
## Install ##
#############

install(
FILES build/output/lib/libfetch_drivers.so build/output/lib/libfetch_drivers_odva.so
DESTINATION ${CATKIN_PACKAGE_LIB_DESTINATION}
)

install(
DIRECTORY build/output/lib/fetch_drivers
DESTINATION ${CATKIN_PACKAGE_LIB_DESTINATION}
PATTERN "build/output/lib/fetch_drivers/*"
PERMISSIONS OWNER_EXECUTE OWNER_WRITE OWNER_READ
GROUP_EXECUTE GROUP_READ
WORLD_EXECUTE WORLD_READ
)

install(
FILES build/output/share/${PROJECT_NAME}/firmware.tar.gz build/output/share/${PROJECT_NAME}/laser_filters.xml
DESTINATION ${CATKIN_PACKAGE_SHARE_DESTINATION}
)
19 changes: 19 additions & 0 deletions fetch_binary_drivers/Makefile.tarball
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,19 @@
all: binary_driver
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why non-standard name?


# TODO: There are some more things to automate.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

More specific?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are too many to list. I had several TODOs and I just combined them into one generic one.
I see your comments also say Why not use DRIVER_VERSION and that's basically when I rolled back and just used the hardcoded path for now.
But it goes into the comments on another comment were we'll need to setup more build/test automation.

For now we're just pulling DRIVER_VERSION = 0.8.0 and until we have a more automated pipeline we'll leave it at this version and just be sure to rebuild that version of our drivers against the latest melodic especially at the time of a sync.

DRIVER_VERSION = 0.8.0
TARBALL = build/fetch-drivers-0.8.0.tar.gz
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not use DRIVER_VERSION

TARBALL_URL = http://packages.fetchrobotics.com/binaries/fetch-drivers-0.8.0.tar.gz
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ditto as above

SOURCE_DIR = build/output
MD5SUM_FILE = fetch-drivers-0.8.0.tar.gz.md5sum
UNPACK_CMD = tar zxvf
include $(shell rospack find mk)/download_unpack_build.mk

binary_driver: $(SOURCE_DIR)/unpacked
echo "binary driver built in: " $(SOURCE_DIR)

clean:
-rm -rf $(SOURCE_DIR)

wipe: clean
-rm -rf build
43 changes: 43 additions & 0 deletions fetch_binary_drivers/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,43 @@
# Fetch Binary Drivers

This is a public binary version of our drivers and firmware for the Fetch Research Platforms.

https://fetchrobotics.com/robotics-platforms/
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Link

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Markdown will render these fine. Is this a style preference?


We have two Fetch Research Platforms. Commonly known as Fetch and Freight. Fetch is the one with the arm.
The drivers and firmware in this package are for both.

https://docs.fetchrobotics.com/
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Link


# Fetch Drivers

The catkin package inside of this folder is called `fetch_drivers`, not `fetch_binary_drivers`.
This is because we've previously been releasing packages which depend on `fetch_drivers`.
We're just changing how we distribute our drivers.

# About

This package should only be needed if you're using one of the Fetch Research Platforms.

Our goal is to better support our our Fetch Research Platform customers through an improved, more automated build and release process. This will get enable us to get updates out faster.

We discussed at [ROSCon 2018](https://roscon.ros.org/2018/) in a talk "Hermetic Robot Deployment Using Multi-Stage Dockers"
by @levavakian & @bluryi some of our internal way of doing build/test/deployment using Docker:
[Video](https://vimeo.com/293626218),
[Slides](https://roscon.ros.org/2018/presentations/ROSCon2018_multistage_docker_for_robot_deployment.pdf).

This public repository, is designed to consume the output of our private `fetch_drivers` repository and enable
Fetch Research Platform users access to the drivers/firmware faster via the official ros packages.

To create the output of our private package, we have a special build job which runs inside of a docker container to ensure we don't accidentally
pull in any private dependencies, and also doesn't output any of the additional commercial robot drivers.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to tell them this?


Previously, we built our drivers on a private buildbot, and hosted them on our own packages site.
We also had a manually synced mirror of the ros packages. This allowed us to ensure we tested the versions of dependancies which were on our mirror.
The old process was not as automated as we would like.

We're in the process of testing ROS Melodic, and setting up our hosted stable mirror, and documenting the upgrade process to ensure Fetch Research Platform customers have a smooth transition.

We will announce to our customers when we're officially ready and supporting ROS Melodic.

See https://docs.fetchrobotics.com for more information.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Link here

1 change: 1 addition & 0 deletions fetch_binary_drivers/fetch-drivers-0.8.0.tar.gz.md5sum
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
1d283854b2406e1945319a57e660c5ec /tmp/fetch-drivers-0.8.0.tar.gz
66 changes: 66 additions & 0 deletions fetch_binary_drivers/package.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,66 @@
<?xml version="1.0"?>
<package format="2">
<name>fetch_drivers</name>
<version>0.0.0</version>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are we not syncing version numbers with the drivers themselves?

<description>
The public fetch_drivers package is a binary only release.

fetch_drivers contains both the drivers and firmware for the fetch and freight research robots.
There should be no reason to use these drivers unless you're running on a fetch or a freight research robot.
This package, is a cmake/make only package which installs the binaries for the drivers and firmware.
</description>

<!-- One maintainer tag required, multiple allowed, one person per tag -->
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are these comments intentionally left in

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They're just left over from the catkin generate package command. I think it was just reminding me to add the maintainers.

<maintainer email="[email protected]">Alexander Moriarty</maintainer>
<maintainer email="[email protected]">Fetch Robotics Open Source Team</maintainer>

<!-- One license tag required, multiple allowed, one license per tag -->
<license>Proprietary</license>


<!-- Url tags are optional, but multiple are allowed, one per tag -->
<url type="website">https://wiki.ros.org/fetch_drivers</url>
<url type="docs">https://docs.fetchrobotics.com</url>
<url type="info">https://fetchrobotics.com/robotics-platforms/</url>


<!-- Author tags are optional, multiple are allowed, one per tag -->
<author email="[email protected]">Alexander Moriarty</author>


<buildtool_depend>catkin</buildtool_depend>

<!-- mk is actually the only build time depend; it just pulls down a the compiled objects. -->
<build_depend>mk</build_depend>

<!-- system dependencies which the drivers dyanmically link against -->
<exec_depend>boost</exec_depend>
<exec_depend>curl</exec_depend>
<exec_depend>python</exec_depend>
<exec_depend>yaml-cpp</exec_depend>

<!-- ros msgs which the drivers depend on -->
<exec_depend>actionlib_msgs</exec_depend>
<exec_depend>diagnostic_msgs</exec_depend>
<exec_depend>fetch_driver_msgs</exec_depend>
<exec_depend>fetch_auto_dock_msgs</exec_depend>
<exec_depend>nav_msgs</exec_depend>
<exec_depend>power_msgs</exec_depend>
<exec_depend>robot_calibration_msgs</exec_depend>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

todo: ensure that these are the same as the ones we used when building the binary drivers.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you won't be able to do that -- the ROS buildfarm / repos only contain the latest debs - once a new version is synced, the old ones go away. Hardcoding the value would make your package uninstallable at best.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mikeferguson: would a nightly build job of our binaries, ensuring we’ve always got the latest dependencies work here?

@cjds and I were hoping to open source the Dockerfile & Python script which builds the output.tar.gz- it won’t be helpful without pull access on our drivers but it would at least make the process transparent

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@moriarty even having the released deb download a nightly binary build is a challenge -- when a sync to public happens, you'd have a ~24 hour window where the version built against public is no longer right. (and that sync happens every ~ 2 weeks, so that's about 7% downtime). Also how do you make it work on both shadow-fixed (where developers tend to test) and the main ros repo?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

😞
@dbking77 & @chadrockey maybe long term we reopen the discussion about refactoring some things to better support public/private drivers to make releasing to research customers easier ❓

We might need a second version setup up and built against shadow-fixed, this still doesn't fix the original problem, and it also wouldn't be clear how to set that up so that the shadow-fixed pulled a fetch-drivers-shadow.tar.gz and the release pulled fetch-drivers.tar.gz especially since currently they're pulling: http://packages.fetchrobotics.com/binaries/fetch-drivers-0.8.0.tar.gz
... Fetch3 & my machine are currently setup against shadow-fixed, but these drivers were built against whatever is inside of

FROM ros:melodic-robot-bionic

(As mentioned @cjds will cleanup the creation process and we plan to put them:
https://github.com/fetchrobotics/fetch_firmware_repackager or rename that repository fetch_drivers_repackager)

And it works now, but that's likely because there hasn't been any API/ABI breaking changes, which is not always guaranteed.
We'll need to check which of the dependencies we have are core dependencies, and which are non-core dependencies.

For the most part, the 7% downtime is a worst case calculation coming from 24hr every 2 weeks. If the dependencies are part of the core ros repositories, I think the API/ABI is stable enough or at least suppose to be... For non-core, and not released by us then it's just a risk that we'll probably need to take.
I don't even know if the melodic sync is triggered every 2 weeks because most of the folks at open robots are developing towards ros2. @jacobperron & @wjwwood?

Our plan, was to setup a mirror of ROS, which we manually trigger a sync on.
So customers with Fetch Research Robots could point to our http://packages.fetchrobotics.com/ and get guaranteed stability. But have the option to get the packages from packages.ros.org either ros or ros-shadow-fixed if they really want to live on the edge and accept some instability.

By pushing this into the public build farm, our internal packages.fetchrobotics.com will become almost a pure mirror, which should have much maintainable for our DevOps team and @bluryi.

If we sync our mirror manually, after testing to know we're not in the 7% downtime, then we'll get stability and more frequent updates.

For the 7% of possible down time for the packages.ros.org I think @erelson will need to update the (not yet existing) documentation to include strong warnings about pointing to packages.fetchrobotics.com or packages.ros.org
The packages.fetchrobotics.com mirror for melodic does not yet exist, we were going to quietly get our packages into melodic, and then setup a mirror once they were in and synced.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@clalancette is the ROS Boss for Melodic, so it's up to him to decide when the syncs happen, though I think they've been trying to keep a regular cadence. Looking at the discourse posts, it's more like once a month, though maybe that will change.

Perhaps you can anticipate the syncs and be prepared with updated packages of your own to sync in order to minimize the period where your debs are out of date. We do usually announce an intention to sync a week or two before doing it, with the intention that people could test it for unintended regressions.

I don't know if this would be relevant as well, but there's this recent announcement by @nuclearsandwich:

https://discourse.ros.org/t/announcing-ros-snapshot-repositories/7705

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My intention is to sync Melodic every two weeks, though I've basically never been able to achieve that due to regressions that I have to fix for every sync. So the cadence has indeed been more like once a month.

I intend to continue to attempt to sync every two weeks unless there is a compelling reason to change that. So if you have reasons you'd like it to change, please let me know and we can consider it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nickswalker and @mikeferguson I wanted to give you a warning: just in case you've been running melodic and testing with Fetch's using ros-shadow-fixed this is now there:

http://repositories.ros.org/status_page/ros_melodic_default.html?q=fetch_

@erelson will do a test on hardware using the ros-shadow-fixed before we make an official announcement with links to upgrade documentation. So: best case, everything works, but it's more likely that the official announcement to the fetch user mailing lists is going to be not the upcoming ros melodic sync, but the one after. If we're really unlucky we could be in one of those 7% downtime scenarios which was mentioned above.

<exec_depend>sensor_msgs</exec_depend>

<!-- ros dependencies which the drivers dynamically link against -->
<exec_depend>actionlib</exec_depend>
<exec_depend>robot_controllers</exec_depend>
<exec_depend>robot_controllers_interface</exec_depend>
<exec_depend>rosconsole</exec_depend>
<exec_depend>roscpp_serialization</exec_depend>
<exec_depend>roscpp</exec_depend>
<exec_depend>rostime</exec_depend>
<exec_depend>urdf</exec_depend>

<!-- The export tag contains other, unspecified, tags -->
<export>
<!-- Other tools can request additional information be placed here -->
</export>
</package>
22 changes: 22 additions & 0 deletions fetch_system_config/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,22 @@
# Fetch System Config

This is the Git Build Package (GBP) repo for Research versions of Fetch/Freight.
All other tools (iso installer, documentation, etc), and the commercial version
of this package, are on the 'master' branch.

# How to Manually Build

```bash
git clone [email protected]:fetchrobotics/fetch_ros.git # -b melodic-devel
cd fetch_ros/fetch_system_config
dpkg-buildpackage -us -uc
# Debians are placed in the parent directory
cd ..
ls *system*.deb
```

# TODO: catkin/standardize

This isn't a GBP anymore, it will be published to:

https://github.com/fetchrobotics-gbp/fetch_robots-release
5 changes: 5 additions & 0 deletions fetch_system_config/debian/changelog
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,5 @@
fetch-system-config (0.1-0) bionic; urgency=medium

* initial release of melodic packages

-- Eric Relson <[email protected]> Fri, 01 Feb 2019 10:50:25 -0800
1 change: 1 addition & 0 deletions fetch_system_config/debian/compat
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
9
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You probably want 11?

Package: debhelper (9.20131227ubuntu1)

even for 14.04

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My 14.04 desktop (still on 3.x kernel... nice and safe...) has 9.x debhelper installed. I don't think there's a reason to bump this requirement presently. And it sounds like the plan is we'll move to using bloom for this later anyways.

34 changes: 34 additions & 0 deletions fetch_system_config/debian/control
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,34 @@
Source: fetch-system-config
Section: main
Priority: optional
Maintainer: Eric Relson <[email protected]>
Build-Depends: debhelper (>= 9.0.0),
dh-systemd (>= 1.5)
Standards-Version: 3.9.4
Homepage: www.fetchrobotics.com

Package: fetch-melodic-config
Architecture: any
Depends: ${misc:Depends},
adduser,
chrony,
openssh-server,
ros-melodic-ros
Description: Configuration for Fetch on Melodic
This package will start ROS Melodic at bootup
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does this mean?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very brief vague statement, but nominally accurate. It installs roscore + robot systemd units which run at computer power-on. I'll reword this probably.

Conflicts: fetch-system-config,
freight-melodic-config,
freight-system-config

Package: freight-melodic-config
Architecture: any
Depends: ${misc:Depends},
adduser,
chrony,
openssh-server,
ros-melodic-ros
Description: Configuration for Freight on Melodic
This package will start ROS Melodic at bootup
Conflicts: fetch-melodic-config,
fetch-system-config,
freight-system-config
36 changes: 36 additions & 0 deletions fetch_system_config/debian/copyright
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,36 @@
Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

Files: *
Copyright: 2015-2018 Fetch Robotics Inc <[email protected]>
2013 I Heart Engineering <[email protected]>
License: BSD-3-clause
Copyright (c) 2015-2018, Fetch Robotics Inc.
Copyright (c) 2013, I Heart Engineering
All rights reserved.
.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
.
* Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above
copyright notice, this list of conditions and the following
disclaimer in the documentation and/or other materials provided
with the distribution.
* Neither the name of the I Heart Engineering nor the names of its
contributors may be used to endorse or promote products derived
from this software without specific prior written permission.
.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.
1 change: 1 addition & 0 deletions fetch_system_config/debian/docs
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
README.md
1 change: 1 addition & 0 deletions fetch_system_config/debian/fetch-melodic-config.install
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
root/* .
Loading