WIP libostree: Add support for finding remote URIs by ref name #782

pwithnall · 2017-04-07T13:29:10Z

This is a strawman PR created for basic feedback on the proposed API and general implementation of support for resolving remote URIs from ref names (as discussed on the mailing list). It’s not a request for detailed feedback. I’ll repurpose this PR later (or create a new one) once the basic API is agreed.

WIP work to add an OstreeRepoFinder interface and implementations which
find remote URIs by ref names, which we consider to be globally unique.
This is an API preview. It compiles, but has not been tested beyond
that, and the implementation is unfinished in various places, and
unpolished everywhere else. It is intended as a strawman for the
proposed API.

The new API is used in a new ostree_repo_find_updates() function, which
resolves a list of ref names to update into a set of remote URIs to pull
them from, which can be treated as mirrors.

A major feature this adds is the ability to automatically pull from
other machines on the local network (as long as they are running an
OSTree server and appropriate Avahi DNS-SD adverts, support for which
will be added separately). Similarly, it adds the ability to pull from
removable file systems without needing further configuration.

This bumps the GLib dependency to 2.50, and adds an optional dependency
on Avahi.

Signed-off-by: Philip Withnall [email protected]

cgwalters · 2017-04-12T01:21:36Z

configure.ac

@@ -75,7 +75,7 @@ AM_PATH_GLIB_2_0(,,AC_MSG_ERROR([GLib not found]))
 dnl When bumping the gio-unix-2.0 dependency (or glib-2.0 in general),
 dnl remember to bump GLIB_VERSION_MIN_REQUIRED and
 dnl GLIB_VERSION_MAX_ALLOWED in Makefile.am
-GIO_DEPENDENCY="gio-unix-2.0 >= 2.40.0"
+GIO_DEPENDENCY="gio-unix-2.0 >= 2.50.0"


Let's factor this out as a separate commit? I think the main drag here is Debian Jessie. Still somewhat old is the Fedora 24 glib2. I honestly don't care about F24 myself but anyways, let's discuss this in a separate PR?

I’ve factored it out twice: e03fd8f bumps the dependency to 2.44, which is what it should be on master, since g_autoptr() requires that. 4e288b0 increases the maximum dependency to 2.50, which is needed for g_drive_is_removable(). If 2.50 is not available, the g_drive_is_removable() call is dropped, which hits performance but not functionality (technically it does, but in reality it’s not a problem).

cgwalters

Wow, OK this is a lot of new code 😄. I have only skimmed it so far. Quality looks generally excellent (as expected).

I think what would help me in the short term is a few comments in strategic places - like PointerTable - I found myself wondering what the heck that is.

Having this be a compile time option is in line with how we do everything else so far, but is going to put me in an interesting position for Fedora at least, since ostree is used for Atomic Host, and while I think Avahi is potentially interesting for bare metal servers, in those types of controlled environments people tend to have more "static" solutions. And Avahi doesn't make much sense at all in a virtualized cloud (AWS/GCE or private). Dunno. Making it a plugin seems like it'd be quite painful though.

Will read more this week. One thing I'd say though is please try to keep a feed of smaller PRs going. Maybe for example we could merge the bloom filter implementation and tests.

cgwalters · 2017-04-12T01:23:39Z

src/libostree/ostree-repo-finder-avahi.c

+  AvahiStringList *l;
+  g_autoptr(GHashTable) out = NULL;
+
+  out = g_hash_table_new_full (g_str_hash, g_str_equal, g_free, (GDestroyNotify) g_bytes_unref);


This is fine, but I'll note we're using C99 decl-after-stmt in more places in ostree now. See this PR for an example.

I’ll try and bear that in mind, although I personally prefer putting all declarations at the start of a block since it helps me visualise the state in a function more easily (and whether there’s too much state and some refactoring is needed).

pwithnall · 2017-04-19T17:03:10Z

I think what would help me in the short term is a few comments in strategic places - like PointerTable - I found myself wondering what the heck that is.

I’ve spruced up the comments in all the commits except the bloom filter and Avahi ones (haven’t had time to do that yet). I will continue working on this.

Having this be a compile time option is in line with how we do everything else so far, but is going to put me in an interesting position for Fedora at least, since ostree is used for Atomic Host, and while I think Avahi is potentially interesting for bare metal servers, in those types of controlled environments people tend to have more "static" solutions. And Avahi doesn't make much sense at all in a virtualized cloud (AWS/GCE or private). Dunno. Making it a plugin seems like it'd be quite painful though.

API-wise, the Avahi stuff is all contained in an implementation of a GInterface, so splitting it out from the rest of the code is not a problem. Doing the dynamic loading side of having it as a plugin would be a bit more of a pain. How about having it as a compile time optional dependency, not a dynamic plugin, but the code is only used if enabled in a configuration file (which is checked at runtime)? Then ‘static’ OSTree setups could ensure the option is turned off, but we don’t have to faff with plugins.

Will read more this week. One thing I'd say though is please try to keep a feed of smaller PRs going. Maybe for example we could merge the bloom filter implementation and tests.

I’ve split it up a bit more. None of the commits are ready for merging yet apart from the really trivial ones. Any commit which is not ready for merging says so in its commit message. Note that the APIs in 313b35f have not actually been tested yet.

I’d like to get a bit more feedback on the APIs (primarily, commit 313b35f) before spending much more time on polishing or testing the other commits.

cgwalters · 2017-04-20T00:52:36Z

src/libostree/ostree-repo-finder-mount.c

+/* Resolve all symlinks in @file’s path, returning a normalised, canonical path
+ * containing no symlinks. This returns the same errors as expand_symlink(). */
+static GFile *
+expand_all_symlinks (GFile         *file,


Isn't this just realpath()? As a general note...for most newer ostree code I tend to have a preference to avoid GFile, at least when accessing a real FS.

Yes, it’s effectively a version of realpath() for GFiles. Using GFile here is a bit pointless, since the file system has to be local in order to have an OSTree repository on it, so GFile brings no benefits. I’ll try and find time to rewrite this to use FDs.

cgwalters · 2017-04-20T00:53:04Z

src/libostree/ostree-repo-finder-mount.c

+      g_autoptr(GFile) ostree_dir = NULL;
+      g_autoptr(GFile) repos_dir = NULL;
+      g_autoptr(GFile) repo_dir = NULL;
+      g_autoptr(GFile) expanded_mount_root = NULL;


This kind of thing is where I think the C99 style comes out nicer.

Yeah. I’ll see how it looks after rewriting to use FDs.

cgwalters · 2017-04-20T00:55:34Z

src/libostree/ostree-repo-finder.h

+  /* TODO: Should I extend this to also support mirrors and metalink? Maybe add a GVariant *metadata too?
+   * For example, should a result be able to force GPG verification? */
+  /* TODO: would it support torrenting? */
+  gchar *uri;


Is there a reason the result isn't just a remote? Among other things, this seems like it'll lose e.g. TLS CA pinning configuration.

In what sense? Do you mean it should be OstreeRemote *remote rather than gchar *uri? I think that would make sense; I didn’t realise OstreeRemote existed.

That would mean ensuring that all the code which handles OstreeRemotes doesn’t assume they’re backed by a configuration file.

It would also mean making OstreeRemote public (since OstreeRepoFinderResult is public). What do you think about that? If so, I’d be inclined to make it a GInterface to allow for multiple remote implementations.

We have a lot of API surface today which takes remote names as strings. It seems OK to me if this is just s,gchar *uri,gchar *remote, - right?

And transparently create some kind of a transient remote internally, with some made-up name (I would probably just use the URI as the name)? Sounds reasonable to me.

What I was thinking about when I made the original comment is - what about the case where we have a predefined remote for the host-ostree and it's all that's available? Does the "find process" return the empty set, then the app (eos-updater) needs to fall back to using it? Or is the existing remote integrated into it?

Synthesizing a remote internally would be good. Right now it's remotes that specify GPG for example (and in some cases which key). So perhaps this API should take a remote as input and use its GPG config?

I think we’re agreed on synthesising a remote and doing s/gchar *uri/gchar *remote_name/ then. 👍

I guess this is where things get interesting - in the case where host-ostree+flatpak are in /ostree/repo (your case AIUI) - do we expect to update both in one "transaction"?

You are correct in your understanding — in Endless OS, both OS and flatpak objects are stored in /ostree/repo, but they come from several remotes (4, at the current count).

I would expect both to be pulled in one transaction, iff the set of ref names passed to ostree_repo_find_remotes() includes OS and flatpak refs. Deploying those refs is a separate issue, and one which I would not necessarily expect to be atomic (although that would be interesting).

I don’t think this is a requirement which changes the implementation: if we were to limit to updating refs from the OS separately from flatpak refs, for example, the code should still support pulling from multiple remote URIs if it found multiple peers on the LAN. Pulling from multiple remote URIs for multiple refs is not more complex, as far as I can see.

(Technically we could limit to pulling from a single remote URI per ref, and that would be a simplification; but at the cost of not being able to use a single transaction to pull ref sets A+B if set A and set B are only available on separate LAN peers. I’d rather not have that limitation.)

Currently, the refname approach allows it, but I think it'd be easier to implement if the "find process" was per remote. We don't expect people to have a lot of those in general. (I.e. we're not doing this per app).

I think we might be talking cross-purposes again. ostree_repo_find_remotes() can’t be per-remote, since at the time it’s called, the possible remotes (including LAN peers and mount points) haven’t been enumerated. Are you using ‘remote’ here to mean ‘a particular repository and set of ref names which are published somewhere by a vendor’ rather than ‘a URI to pull from’?

What I was thinking about when I made the original comment is - what about the case where we have a predefined remote for the host-ostree and it's all that's available? Does the "find process" return the empty set, then the app (eos-updater) needs to fall back to using it? Or is the existing remote integrated into it?

As the branch currently stands, ostree_repo_find_remotes() will return the empty set, but that’s not the intention. I think clients shouldn’t have to do any fallbacks from ostree_repo_find_remotes().

My original intention was that OstreeRepoFinderConfig would supersede the [remote "blah"] groups in /ostree/repo/config with /etc/ostree/refs.d/$ref_name files instead, but I admit I haven’t actually worked out a transition path for it. I suspect we might need an additional OstreeRepoFinderOldConfig (strawman name) which returns results from the OstreeRepo’s config file. It would return all the configured remotes from there, then the code in ostree_repo_find_remotes() which downloads the summary files and checks them would filter out the refs which aren’t in each remote (i.e. it would assign the OS refs to the OS remote and the flatpak refs to the flatpak remote). That would mean downloading more summary files than ostree_repo_pull() currently does (one per remote, rather than one overall), but this shouldn’t really be a problem given that they’re cached locally.

The way I've been thinking of this is that the RepoFinder is basically a much fancier mirrorlist type implementation for existing remotes. Basically, flatpak update would try using repofinder, and if that was empty, would just fall back to its existing remote.

It sounds like you're thinking of this more like "eos-updater does everything"? What would flatpak update do? Do you see it being ported to this?

The way I've been thinking of this is that the RepoFinder is basically a much fancier mirrorlist type implementation for existing remotes. Basically, flatpak update would try using repofinder, and if that was empty, would just fall back to its existing remote.

I think we’re still talking a bit cross-purposes here. What do you mean by ‘existing remote’? The Avahi stuff, by its very nature, cannot rely on ‘existing remotes’ since the set of peers on the local network can vary.

It sounds like you're thinking of this more like "eos-updater does everything"? What would flatpak update do? Do you see it being ported to this?

Correct, I am thinking of this as effectively a replacement for the existing ostree_repo_pull() API. flatpak update would definitely be ported to this, and would pass it the refs for the set of flatpaks it wants to update (most likely, all the flatpaks the user has installed).

I hope I mentioned this before (I probably didn’t): the overall goal here is that flatpak can do updates from LAN and USB remotes, just like eos-updater can; and that the code bases for the two converge so that all the underlying LAN and USB functionality is in libostree. We probably eventually want to gut eos-updater and move it into a GNOME Software plugin, but that’s less relevant here.

Synthesizing a remote internally would be good. Right now it's remotes that specify GPG for example (and in some cases which key). So perhaps this API should take a remote as input and use its GPG config?

I think we’re agreed on synthesising a remote and doing s/gchar *uri/gchar *remote_name/ then. 👍

Gah, this won’t work, since the remotes are cached in the OstreeRepo, which the OstreeRepoFinder implementations don’t have access to (and it doesn’t make sense for them to have access to). I’ll see what I can come up with, but it might mean making OstreeRemote public (even if most API continues to use const gchar *remote to access remotes by name, for simplicity).

cgwalters · 2017-04-20T01:10:39Z

tests/test-repo-finder-config.c

+
+/* Recursively delete @file and its children. @file may be a file or a directory. */
+static gboolean
+rm_rf (GFile         *file,


This is glnx_shutil_rm_rf_at().

Aha, thanks. That’s a good incentive for me to FD-ise this code.

cgwalters · 2017-04-20T01:19:25Z

As far as Avahi, compile time is OK for now. Particuarly if we can make it a plugin down the line, and I think we could?

cgwalters · 2017-04-20T01:24:02Z

src/libostree/ostree-repo-pull.c

+                          GCancellable         *cancellable,
+                          GError              **error)
+{
+  /* TODO: Support disabling certain repo finders. */


The thing that has me hesitating a bit about the "try everything" model - it feels like we'll likely end up needing to hardcode things like "prefer USB finder first". But even there, I worry about needing some mechanism for the client app to configure individual finders. We can theoretically do any arbitrary extensions later via new API, but it's worth thinking about a bit now maybe?

I’ve changed this locally to take an OstreeRepoFinder **finders parameter. If that’s NULL then a list of default finders will be used.

cgwalters · 2017-04-20T01:25:00Z

src/libostree/ostree-repo-pull.c

+            }
+        }
+
+      /* TODO: ensure this checks the commit signature; or that the checksum matches the downloaded content */


It doesn't do either of those.

cgwalters · 2017-04-20T01:26:51Z

src/libostree/ostree-repo-pull.c

+                                            refs_to_pull->pdata);
+
+      /* TODO: Progress will yo-yo here. */
+      ostree_repo_pull_with_options (self, result->uri, local_options, progress,


Yeah...would be really messy to try to drive multi-remote logic down farther unfortunately.

pwithnall · 2017-04-20T15:07:03Z

As far as Avahi, compile time is OK for now. Particuarly if we can make it a plugin down the line, and I think we could?

We could indeed make it a plugin further down the line, as long as we were careful about the API for determining which OstreeRepoFinders to use (i.e. we don’t hardcode a gboolean use_avahi, for example).

pwithnall · 2017-04-25T21:04:26Z

@cgwalters and I have discussed this over the course of a couple of calls, and I think we’ve now got a direction sorted out for it. The new API is roughly the right shape, and we’re happy with the split from ostree_repo_pull() into two phases: ostree_repo_find_remotes() (which finds remotes and downloads metadata) and ostree_repo_pull_from_remotes() (which pulls content).

I need to spend a few days updating this branch to reflect what we’ve decided on (which it currently doesn’t).

I’ve split some of the minor, unrelated, changes out into PR #810.

Notes from the calls

2017-04-21

How does updating a single app work in future? -> provide a single ref
How are flatpakref files handled in future? -> create a remote from them

eliminate the preordained knowledge about binding between refs and remote configurations
GPG keys are currently bound to remotes; we want them bound to refs

BitTorrent is an (eventual) use case: it could be used within data centres, for example

Need an ostree command line tool to visualise where content can come from (i.e. the results of find_remotes())

Philip to think about how GPG keys are handled in ostree_repo_pull()
Could use dry-run option for splitting metadata from commit downloads in ostree_repo_pull()

If we ignore the remote config when we pull from multiple refs, we lose TLS pinning
TLS pinning is really important

Use case for pulling from the internet remote first: if you got the app/OS from the internet, and expect to continue getting updates from there, you would want to know if somehow you randomly started getting updates from somewhere else — the corporate workspace environment

When do we pull the superblock? better define the split between metadata and data

How do we get progress information out of ostree_repo_pull_from_remotes()? we want stats per ref => does this fit into OstreeAsyncProgress?

Can branches= in /ostree/repo/config replace the existing refs.d code in the lan-and-usb branch?

Actions:

Philip to check whether we can make the new code subordinate to ostree_repo_pull()?
Catch up on Monday

2017-04-25

Colin is open to solving the problem with a new API:

dividing line is between 1) remote finding+metadata 2) content

Could retrofit this onto ostree_repo_pull() using caching in the OstreeRepo instance
OK with introducing a new API — what else can we fix at the same time?
Download static delta superblock in find_remotes() phase
ostree_repo_pull() was not designed for sync vs async — probably should be
What is good prior art for progress reporting?

Don't need progress reporting for phase 1? Maybe we do; similarly, can we ensure that the mirrors which are chosen are reported?
Some move to use journal for ostree-as-system - should we do that for flatpak too?
Negative remotes:
Use case: Do we need to show if we didn't find the refs? What about the USB stick case where user might want to see that it's actually outdated.

=> Return an OstreeRepoFinderResult with an empty refs array

Discussion about refactoring existing pull on top:

Sharing GPG
Progress reporting

API stability:

OSTree’s release cadence is too high to deal with unstable API in master
Discussed options: #define OSTREE_I_KNOW_THIS_IS_UNSTABLE ; have a configure-time option for enabling everything (requires ifdefs in the .sym file, but it’s possible)

=> go with a compile time option; can we get PR testing with the option enabled? Travis stuff

EOS would be released with these API changes before they are made stable on OSTree master; could test the entire stack on EOS before making any of it stable in OSTree

refs.d vs config: 0 hits in flatpak code; need to ask Alex or Matthias why it exists and whether we can make it useful for OstreeRepoFinderConfig

=> can we actually just solve this by looking at the local vs remote ref names in the repository?
=> need to think about how GPG keys are bound, since the remote config is what traditionally binds GPG keys to refs (via a remote)

Discussion about remotes, GPG keys, and bindings:

OSTree currently has the model where GPG keys are bound to remotes
Philip was thinking about a model where GPG keys are bound to refs
Probably best to not change how OSTree works at the moment, since there are many assumptions built around binding keys to remotes
This means the OstreeRepoFinder code is going to have to have some concept of a ‘canonical remote’ somewhere, which is the one providing the GPG key to use
Hopefully this canonical remote code can be kept self-contained and not leak into the API

Actions:

Philip to copy this Etherpad into the github issue once it’s tidied up
Philip to split out landable changes from PR
Philip to look at replacement for the branch’s current refs.d code (OstreeRepoFinderConfig) which uses local vs remote refs; see what flatpak does with xa.main-ref
Philip to continue working on the branch and to hide all new API behind a configure-time option; look at progress reporting; make things async; support negative results; download static delta superblocks in phase 1
Colin to refactor GPG handling for downloads in ostree_repo_pull()
Colin to look at PR testing for the new configure-time option (once the option actually exists)

rh-atomic-bot · 2017-04-29T12:01:25Z

☔ The latest upstream changes (presumably cbe3989) made this pull request unmergeable. Please resolve the merge conflicts.

rh-atomic-bot · 2017-05-08T01:07:14Z

☔ The latest upstream changes (presumably f3cc0eb) made this pull request unmergeable. Please resolve the merge conflicts.

rh-atomic-bot · 2017-05-08T17:51:57Z

☔ The latest upstream changes (presumably 9690a54) made this pull request unmergeable. Please resolve the merge conflicts.

rh-atomic-bot · 2017-05-10T15:22:47Z

☔ The latest upstream changes (presumably 63497c6) made this pull request unmergeable. Please resolve the merge conflicts.

rh-atomic-bot · 2017-05-19T15:11:31Z

☔ The latest upstream changes (presumably add88c3) made this pull request unmergeable. Please resolve the merge conflicts.

Add an initial OstreeRepoFinder interface (but no implementations), which will find remote URIs by ref names, which we consider to be globally unique. This is an API preview. It compiles, but has not been tested beyond that, and the implementation is unfinished in various places, and unpolished everywhere else. It is intended as a strawman for the proposed API. The new API is used in a new ostree_repo_find_updates() function, which resolves a list of ref names to update into a set of remote URIs to pull them from, which can be treated as mirrors. It is an attempt to generalise resolution of the URIs to pull from, and to generalise determination of the order and parallelisation which they should be downloaded from in. Includes fixes by Krzesimir Nowak <[email protected]>. Signed-off-by: Philip Withnall <[email protected]>

This is a basic implementation of OstreeRepoFinder which resolves ref names to remote URIs by looking them up in configuration files in /etc/ostree/refs.d. Unit tests are included. Signed-off-by: Philip Withnall <[email protected]>

This is a basic implementation of OstreeRepoFinder which resolves ref names to remote URIs by looking for them on any currently mounted removable storage volumes. The idea is to support OS and app updates via USB stick. This commit is unpolished and not ready to be merged. It is intended as a strawman for feedback. Unit tests are included. This bumps libostree’s maximum GLib dependency from 2.44 to 2.50 for g_drive_is_removable(). If GLib 2.50 is not available, the call which needs it will be omitted and the OstreeRepoFinderMount implementation will scan all volumes (not just removable ones); this is a performance hit, but not a functionality hit. Signed-off-by: Philip Withnall <[email protected]>

This will be used in an upcoming commit. It adds a basic bloom filter implementation, using the SipHash family of hash functions. The implementation (including its parameter choices and hash functions) will become a protocol detail in future, so must not be changed so that its output is bitwise incompatible between OSTree versions. This commit is unpolished and not ready to be merged. It is intended as a strawman for feedback. Unit tests are included. Signed-off-by: Philip Withnall <[email protected]>

This is a more complex implementation of OstreeRepoFinder which resolves ref names to remote URIs by looking for refs advertised by peers on the local network using DNS-SD records and mDNS (Avahi). The idea is to allow OS and app updates to be propagated over local networks, without the internet. It requires an OSTree server and code to generate the DNS-SD adverts in order to be fully functional — support for this will be added separately. This commit is unpolished and not ready to be merged. It is intended as a strawman for feedback. Unit tests are included. Includes fixes by Krzesimir Nowak <[email protected]>. Signed-off-by: Philip Withnall <[email protected]>

This is a wrapper around the new ostree_repo_find_remotes() method; it tries to find available remotes which can serve updates for the user-provided refs. Signed-off-by: Philip Withnall <[email protected]>

This will pull the remotes after finding them. This potentially needs to go in its own pull-from-remotes built-in command, but it will be fine here for now. Signed-off-by: Philip Withnall <[email protected]>

I can't get the damn thing to link

need to add the remote to the repo just in case. usually remotes we get from avahi are not added, so reading configuration in the pulling code fails. also, do not clear the error prematurely - that caused the find-remotes --pull command to "succeed" while actually not pulling anything at all.

pwithnall · 2017-06-12T22:53:20Z

I’ve opened a new version of this as PR #924, ready for review.

pwithnall force-pushed the lan-and-usb branch 3 times, most recently from e58c07b to aec1f6c Compare April 11, 2017 14:25

cgwalters reviewed Apr 12, 2017

View reviewed changes

cgwalters added the WIP label Apr 12, 2017

pwithnall force-pushed the lan-and-usb branch from aec1f6c to 148512b Compare April 19, 2017 15:25

cgwalters reviewed Apr 20, 2017

View reviewed changes

pwithnall mentioned this pull request Apr 21, 2017

Convenience API additions GNOME/libglnx#42

Merged

krnowak mentioned this pull request Apr 21, 2017

Add support for binary values in TXT records in service files avahi/avahi#116

Merged

pwithnall mentioned this pull request Apr 25, 2017

Minor fixes #810

Closed

pwithnall force-pushed the lan-and-usb branch from 148512b to df46a16 Compare April 25, 2017 20:56

pwithnall mentioned this pull request Apr 28, 2017

Rework OstreeAsyncProgress API to use GVariant #819

Closed

pwithnall force-pushed the lan-and-usb branch from df46a16 to 3e444f1 Compare April 28, 2017 20:10

pwithnall force-pushed the lan-and-usb branch 5 times, most recently from 974a8d8 to d27fa6f Compare May 5, 2017 10:32

pwithnall force-pushed the lan-and-usb branch from d27fa6f to 644490f Compare May 8, 2017 09:27

pwithnall force-pushed the lan-and-usb branch 2 times, most recently from a1541c7 to 693e44f Compare May 8, 2017 15:06

pwithnall force-pushed the lan-and-usb branch from 693e44f to a3ca352 Compare May 9, 2017 15:26

cgwalters mentioned this pull request May 11, 2017

Summary file races #487

Open

pwithnall force-pushed the lan-and-usb branch 3 times, most recently from 2793957 to 43c487b Compare May 19, 2017 09:23

pwithnall force-pushed the lan-and-usb branch 5 times, most recently from a549f3c to 4f210d3 Compare May 23, 2017 17:21

pwithnall and others added 8 commits May 29, 2017 12:41

find-remotes: Add a find-remotes built-in command

75f5671

This is a wrapper around the new ostree_repo_find_remotes() method; it tries to find available remotes which can serve updates for the user-provided refs. Signed-off-by: Philip Withnall <[email protected]>

find-remotes: Add pull support to the find-remotes built-in command

a6228d6

This will pull the remotes after finding them. This potentially needs to go in its own pull-from-remotes built-in command, but it will be fine here for now. Signed-off-by: Philip Withnall <[email protected]>

WIP skip building avahi tests

008dffb

I can't get the damn thing to link

pwithnall force-pushed the lan-and-usb branch from 4f210d3 to 008dffb Compare May 29, 2017 11:42

pwithnall closed this Jun 12, 2017

pwithnall deleted the lan-and-usb branch June 12, 2017 16:01

pwithnall mentioned this pull request Jun 12, 2017

Support peer-to-peer discovery and fetching of refs (LAN and USB) #924

Closed

WIP libostree: Add support for finding remote URIs by ref name #782

WIP libostree: Add support for finding remote URIs by ref name #782

Conversation

pwithnall commented Apr 7, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cgwalters left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pwithnall commented Apr 19, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pwithnall Apr 21, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cgwalters commented Apr 20, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pwithnall commented Apr 20, 2017

pwithnall commented Apr 25, 2017

Notes from the calls

2017-04-21

2017-04-25

rh-atomic-bot commented Apr 29, 2017

rh-atomic-bot commented May 8, 2017

rh-atomic-bot commented May 8, 2017

rh-atomic-bot commented May 10, 2017

rh-atomic-bot commented May 19, 2017

pwithnall commented Jun 12, 2017

pwithnall commented Apr 7, 2017 •

edited

Loading

cgwalters left a comment •

edited

Loading

pwithnall Apr 21, 2017 •

edited

Loading