similar to: reposurgeon progress

Well, that wasn't as nasty as I feared it would be. Turns out that in the general case it's possible to partition a mixed-branch revision into branch cliques and generate multiple import-stream commits, one for each affected branch. We lose only if the split commit is the source of a later directory copy; I have a check for that that says, basically, "if you see this fatal error,

Subtle bug, simple fix. The problem was introduced by my change that used content hashes to avoid issuing duplicate blobs. The generated .gitignore nodes didn't have a Content-Hash header, which meant all .gitignores were treated as though they had the same *empty* hash. 2.0pre8 is at: http://www.catb.org/esr/nut-conversion/nut-conversion.tar.gz Please check that the .gitignores look OK

There is now a public reposurgeon repository at: git at gitorious.org:reposurgeon/reposurgeon.git I've tagged 2.0pre9 there, for two purposes: * Charles can verify that I've solved the missing-files problem. * Hartmut can rework the few of his patches I didn't merge into reposurgeon. Charles, our next and final challenge is to generate proper merge commits in the NUT repo

On Nov 13, 2012, at 3:37 PM, Arnaud Quette wrote: > Fix Buildbot failures on commit r3776 One small request in the commit messages: please mention exact commit numbers only if the commit is hard to find. Something like "fix buildbot failures from previous commit" is specific enough, without making the reader look up a specific commit number. The reason is that it will be harder to

Hi Eric, One corner case I ran across when building from a reposurgeon-generated tree is that .gitignore files do not seem to be generated when a directory is created at the same time as its svn:ignore property is set. In NUT, this manifests itself in r3109: http://trac.networkupstools.org/projects/nut/changeset/3109 Trac doesn't show it there, but scripts/avahi was created in that commit,

I have created a git repository for the three metadata files used in the NUT-UPS conversion. The purpose of this is to allow Charles to edit the lift script. The repository is at git at gitorious.org:reposurgeon/nut-conversion.git This supplements the reposurgeon 2.0pre repository at git at gitorious.org:reposurgeon/reposurgeon.git Here is the current state of play: 1. reposurgeon is

I've solved the detached-branch problem! It wasn't actually the branch-rename overwrites that were doing this - turns out I was trying to remove cvs2svn-generated junk commits too soon and in the process deleting critical branch links. I've uploaded a new tarball to http://www.catb.org/esr/nut-conversion/nut-conversion.tar.gz with the 2.0-pre3 version of reposurgeon in it. That

Argh! habits are hard to change. I've fixed the message again on the server, to satisfy the git format... Arnaud -- Linux / Unix Expert R&D - Eaton - http://powerquality.eaton.com Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/ Debian Developer - http://www.debian.org Free Software Developer - http://arnaud.quette.free.fr/ 2012/1/23 Arnaud Quette <aquette

I've pushed 2.10pre to git at gitorious.org:reposurgeon/reposurgeon.git and there's a new version of the conversion metadata at git at gitorious.org:reposurgeon/nut-conversion.git I'm not entirely happy with the branch link deduction, but I think this is the best we're going to do without manual intervention to break some harmless but spurious parent links. The

Dear developers, thanks to Charles (Lepple) and ESR hard work, we are now able to finalize our migration from Subversion to Git, on Alioth. As of now, our Subversion repository on Alioth<https://alioth.debian.org/scm/?group_id=30602>is FROZEN! Any new svn commit may simply be discarded, so beware! Most active developers are currently using github, as a temporary mean. But if you have any

(Copied to Dave Hart at the NTP project, who's interested in the code's progress for non-NUTty reasons. Dave, the background is that I'm doing a trial conversion of the Network UPS Tools repo.) First, repostreamer per se is dead. As it evolved it kept pulling in more bits of code from reposurgeon until I said "screw it!" and merged the repostreamer logic in as a reposurgeon

Dear Ladies and Gentlemen, I have several old, yet functioning APC Smart-UPS (Model 600LS, Part AP600I, Firmware 6JI, no EEPROM, from 1991). They are not supported by Powerchute any more. I run NUT 2.6.5-4 on Windows XP SP3. I use COM1 port with cable 940-0024C. The connection fails with APC Smart protocol driver 3.0 (2.6.3-3534:3540M), APC command table version 3.0 or higher - it works with APC

Hello. Trouble to communicate with APC SmartUPS via serial port. UPS connected to the com1 port on windows host. Communication witch hyperterm works well. There is a log: YSM ^ASmart-UPS SC1000 n5S0713T63247 m03/29/07 L240.0 B27.10 apcupsd also can communicate with the UPS and works well. running apcsmart -a ups gives the following: com1: device reports different attributes than what were set

On several occasions I have seen the apcsmart process runaway using 100% CPU while filling my syslog partition by logging the following syslog entries at an incredible rate. I have seen up to 21,800 log entries PER SECOND of the following nature: --[snip]-- Jun 25 10:06:38 servername apcsmart[4012]: Communications with UPS lost: Communications with UPS lost - check cabling Jun 25 10:06:38

On 2014-01-14 10:12, dstrr wrote: > Hello. > Trouble to communicate with APC SmartUPS via serial port. > UPS connected to the com1 port on windows host. > Communication witch hyperterm works well. > There is a log: > > YSM > ^ASmart-UPS SC1000 > n5S0713T63247 > m03/29/07 > L240.0 > B27.10 > > apcupsd also can communicate with the UPS and works well. >

G'day y'all, Here's a tiny patch set for drivers/apcsmart.c and drivers/apcsmart.h. Adds APC SmartUPS 1250 ("8QD" case) + 940-0024C recognition to apcsmart. (Unpatched apcsmart.c v1.99.8 misidentifies the SmartUPS 1250 as a "dumb" UPS.) For NUT 2.0.5+. NUT 2.0.5: Patches apply successfully. Builds successfully. Works as expected under Ubuntu 7.04. NUT 2.2:

Hi! Anyone else experiencing performance problems when using the new monorepo? My experience is that performance of gitk (and git log) sometimes is really bad when working in the monorepo. I've mainly seen it when using gitk on specific files/directories, but since gitk seems to be using "git log --no-color -z --pretty=raw --show-notes --parents --boundary HEAD -- <file>" it

Hans van Kranenburg writes ("Re: git workflow, redux"): > On 08/23/2018 08:07 PM, Ian Jackson wrote: > > I think git-debrebase is going to be easier for all these things than > > the current approach. > > Ok, let's try it! Thanks a lot for doing the above writeup. Great, thanks. (I hope it's OK that I have snipped most of your responses to the discussion,

Hi Charles, On Monday, 27. June 2016 08:59:02 Charles Lepple wrote: > > is there a way to query from the cmdline if the UPS data is stale? > > The "data stale" state applies to the entire set of variables for an UPS, > so if the exit code of `upsc` is zero, the data set is not stale. > > "upsc" outputs a lot of information, but not if the data is stale.

Sorry for a bit longer delay than I anticipated, I was stuffed with the work. This is the next iteration of the patch adding some functionality to apcsmart driver, and relying on 'ignorelb' recently added. Follow up from previous thread: http://www.mail-archive.com/nut-upsdev at lists.alioth.debian.org/msg02331.html Main differences is that V3 is split into many small patches, so the