> However, this was not an error I was expecting to see when rebuilding: > > http://buildbot.networkupstools.org/public/nut/builders/Debian-website/builds/55/steps/shell/logs/stdio > [...] > Makefile:796: *** target pattern contains no '%'. Stop. > > Any ideas?I think we don't support colons in names of files and dirs: - https://github.com/networkupstools/nut-ddl/commit/3a68bbdfc6e3274aad027707d71f8a77fdbaa12d - https://github.com/networkupstools/nut-ddl/commit/3861afc614490f2a626059514b47011c754bd27c Tomorrow (now I can't keep my eyes open) I'll address that: we can either add colons to the list of unsupported characters ( https://github.com/networkupstools/nut-ddl#a-message-to-you-rudy ) and rename those 2 files, or try to escape them - preferences?> Also, what do I do afterwards to push to GitHub?I think that it should be enough to rsync (deleting files not present in source dir from destination dir, but excluding '/.git/', '/CNAME', '/source/' and '/package/') the generated 'output' directory to the dir coupled with 'networkupstools.github.io' repository, go to that dir, git add/commit, then push to GitHub. Tangentially, I still think that we should move 'source' and 'package' dirs to their own repositories and add them as submodules of 'nut-website', then we will not need to ignore those two dirs and we should be able to generate indices for them and further automate the release process, something like this: https://github.com/zykh/nut-website/tree/source-package (with 'source' and 'package' added as dirs/submodules).
On Jun 8, 2016, at 7:47 PM, hyouko at gmail.com wrote:> >> However, this was not an error I was expecting to see when rebuilding: >> >> http://buildbot.networkupstools.org/public/nut/builders/Debian-website/builds/55/steps/shell/logs/stdio >> [...] >> Makefile:796: *** target pattern contains no '%'. Stop. >> >> Any ideas? > > I think we don't support colons in names of files and dirs: > - https://github.com/networkupstools/nut-ddl/commit/3a68bbdfc6e3274aad027707d71f8a77fdbaa12d > - https://github.com/networkupstools/nut-ddl/commit/3861afc614490f2a626059514b47011c754bd27c > > Tomorrow (now I can't keep my eyes open) I'll address that: we can > either add colons to the list of unsupported characters ( > https://github.com/networkupstools/nut-ddl#a-message-to-you-rudy ) and > rename those 2 files, or try to escape them - preferences?I went ahead and renamed them. Colons really don't belong in filenames. Even though the files were named based on the model strings from SNMP, I think they are more of an outlet description than part of the model name. I will try to remember to update the list of unsupported characters.>> Also, what do I do afterwards to push to GitHub? > > I think that it should be enough to rsync (deleting files not present > in source dir from destination dir, but excluding '/.git/', '/CNAME', > '/source/' and '/package/') the generated 'output' directory to the > dir coupled with 'networkupstools.github.io' repository, go to that > dir, git add/commit, then push to GitHub.Hmm, I will have to look at some of the dependencies - the "Last updated" dates aren't getting modified. (I am just doing a "make" (all) rather than "make dist" since I don't have a new NUT tarball or the GPG key.)> Tangentially, I still think that we should move 'source' and 'package' > dirs to their own repositories and add them as submodules of > 'nut-website', then we will not need to ignore those two dirs and we > should be able to generate indices for them and further automate the > release process, something like this: > https://github.com/zykh/nut-website/tree/source-package (with 'source' > and 'package' added as dirs/submodules).I like the looks of the source-package branch. I don't think I have enough experience with submodules to say what I would prefer, so I'll leave that up to you. Let me know if you'd like help with anything else. -- Charles Lepple clepple at gmail
> I will try to remember to update the list of unsupported characters.Done.> Hmm, I will have to look at some of the dependencies - the "Last updated" dates aren't getting modified. (I am just doing a "make" (all) rather than "make dist" since I don't have a new NUT tarball or the GPG key.)What do we want to do with 'Last updated' and 'Version' in footers? I mean, when not working in a virgin repo, it may happen that targets are newer than prerequisites and therefore not rebuilt... which leaves us with mixed dates (not a big problem, after all) and versions (which annoy me the most). Plus, at the moment, pages built directly by 'nut-website' get their version from the last tag in NUT (minus the additional infos about the commit, e.g. 2.7.4), protocols don't get any version at all (but their own, if set), while pages under 'nut' submodule get their version from NUT's 'configure.ac' (e.g. 2.7.4.1). If I recall correctly, in a previous topic you mentioned reproducible builds and proposed to save version in a file. With that in mind, I think we could do something like this: - in 'nut-website' repo: store the output of `git describe --tags` (done on 'nut' submodule, without removing commit infos) in a git-ignored file, but only if that file doesn't exist or version is not the same, and then add that file as a prerequisite to every file: each page will then get the same (most recent NUT) version but its own timestamp and it will only be rebuilt when version changes, - in 'nut' repo: do the same for builds between releases, while for tarballs do not store commit infos and add a second prerequisite file (or maybe we could use the same file) with the timestamp: then if this timestamp exists, pages will use it, otherwise (i.e. non-tarball builds) they'll get their own.> I like the looks of the source-package branch. I don't think I have enough experience with submodules to say what I would prefer, so I'll leave that up to you. Let me know if you'd like help with anything else.I've created two new repositories for source and package archives, added them as submodules of 'nut-website', rebased and merged that branch and updated all submodules. I was about to push the freshly built files to 'networkupstools.github.io' repo, but came across a file Arno added to the repo while publishing 2.7.4 (67a4c0e), but that we lack in 'nut-website' repo: https://github.com/networkupstools/networkupstools.github.io/blob/master/protocols/snmp/BESTPOWER-MIB.mib It's not listed in 'ups-protocols.txt', either, but it seems to be the real match for 'bestpower-mib.c' (see how '.1.3.6.1.4.1.2947.1.1.8.0' is mapped to 'manufacturing date', while http://powerquality.eaton.com/Support/Software-Drivers/Downloads/connectivity-firmware/bestpwr2.mib -which appears to be a newer revision of that file- lists that as 'installation date'). What should we do with it? Arno?