I need a decoder ring for the qacct output
Hi, I'm using 'qacct -P' in the hope of tracking metrics on a per project basis. I am getting data out of qacct, however I don't fully comprehend what the data is trying to tell me. I've searched the man pages and web for definitions of the output of qacct, but I have not been able to find a complete reference (just bits and pieces here and there). Can anyone point me to a complete reference so that I can better understand the output of qacct? Thank you, -- Mun
Re: configure: error: failed to recognize APR_INT64_T_FMT on this platform
On 24.04.2019 19:43, ken edward wrote: > Does anyone have an idea how to fixthis error: > > > ./configure --with-sqlite=/u01/tomcat/scm/sqlite-autoconf > --with-apxs=/u01/tomcat/scm/apache2.4.39kerb/bin/apxs > --prefix=/u01/tomcat/scm/subversion --enable-javah > l --with-jdk=/u01/weblogic/java/jdk1.8.0_201 > --with-zlib=/u01/tomcat/scm/zlib-1.2.11 > --with-apr-util=/u01/tomcat/scm/apr-util-1.6.1/bin/apu-1-config > --with-apr=/u01/tomcat/scm/apr-1.7.0/bin/apr-1-con > fig --with-lz4=internal --with-utf8proc=internal CPPFLAGS=-DHAVE > > configure: Configuring python swig binding > checking for Python includes... -I/usr/include/python2.7 > checking for compiling Python extensions... gcc -pthread -fPIC > checking for linking Python extensions... gcc -pthread -shared -Wl,-z,relro > checking for linking Python libraries... -Wl,-z,relro > checking for apr_int64_t Python/C API format string... > configure: error: failed to recognize APR_INT64_T_FMT on this platform Don't use APR 1.7.0. It changed the way it sets APR_INT64_T_FMT in a way that interferes with Subversion's configuration for the Python bindings. This is fixed in our trunk, but not in 1.12. -- Brane
[ANNOUNCE] Apache Subversion 1.12.0 released
I'm happy to announce the release of Apache Subversion 1.12.0. Please choose the mirror closest to you by visiting: https://subversion.apache.org/download.cgi#supported-releases This is a stable feature release of the Apache Subversion open source version control system. SHA-512 checksums are available at: https://www.apache.org/dist/subversion/subversion-1.12.0.tar.bz2.sha512 https://www.apache.org/dist/subversion/subversion-1.12.0.tar.gz.sha512 https://www.apache.org/dist/subversion/subversion-1.12.0.zip.sha512 PGP Signatures are available at: https://www.apache.org/dist/subversion/subversion-1.12.0.tar.bz2.asc https://www.apache.org/dist/subversion/subversion-1.12.0.tar.gz.asc https://www.apache.org/dist/subversion/subversion-1.12.0.zip.asc For this release, the following people have provided PGP signatures: Julian Foad [4096R/1FB064B84EECC493] with fingerprint: 6011 63CF 9D49 9FD7 18CF 582D 1FB0 64B8 4EEC C493 Stefan Sperling [2048R/4F7DBAA99A59B973] with fingerprint: 8BC4 DAE0 C5A4 D65F 4044 0107 4F7D BAA9 9A59 B973 Johan Corveleyn [4096R/B59CE6D6010C8AAD] with fingerprint: 8AA2 C10E EAAD 44F9 6972 7AEA B59C E6D6 010C 8AAD Stefan Fuhrmann [4096R/99EC741B57921ACC] with fingerprint: 056F 8016 D9B8 7B1B DE41 7467 99EC 741B 5792 1ACC Release notes for the 1.12.x release series may be found at: https://subversion.apache.org/docs/release-notes/1.12.html You can find the list of changes between 1.12.0 and earlier versions at: https://svn.apache.org/repos/asf/subversion/tags/1.12.0/CHANGES Questions, comments, and bug reports to users@subversion.apache.org. Thanks, - The Subversion Team
configure: error: failed to recognize APR_INT64_T_FMT on this platform
Does anyone have an idea how to fixthis error: ./configure --with-sqlite=/u01/tomcat/scm/sqlite-autoconf --with-apxs=/u01/tomcat/scm/apache2.4.39kerb/bin/apxs --prefix=/u01/tomcat/scm/subversion --enable-javah l --with-jdk=/u01/weblogic/java/jdk1.8.0_201 --with-zlib=/u01/tomcat/scm/zlib-1.2.11 --with-apr-util=/u01/tomcat/scm/apr-util-1.6.1/bin/apu-1-config --with-apr=/u01/tomcat/scm/apr-1.7.0/bin/apr-1-con fig --with-lz4=internal --with-utf8proc=internal CPPFLAGS=-DHAVE configure: Configuring python swig binding checking for Python includes... -I/usr/include/python2.7 checking for compiling Python extensions... gcc -pthread -fPIC checking for linking Python extensions... gcc -pthread -shared -Wl,-z,relro checking for linking Python libraries... -Wl,-z,relro checking for apr_int64_t Python/C API format string... configure: error: failed to recognize APR_INT64_T_FMT on this platform
Re: EXTERNAL: Re: svn version 1.10 lack of robustness in presence of flaky network
On Wed, Apr 24, 2019 at 12:41 PM Marlow, Andrew wrote: > -Original Message- > From: Johan Corveleyn ... > > Where are you checking out your software? Is it on a local disk? > Yes. Okay, then there must be something strange with this local disk; or a second process is interfering with 'svn' trying to lock its database. In any case, no network is involved then, so "flaky network" can't be the cause of your problem. The error you received specifically points to a problem while locking the working copy database: [[[ svn: E200033: Another process is blocking the working copy database, or the underlying filesystem does not support file locking; if the working copy is on a network filesystem, make sure file locking has been enabled on the file server svn: E200033: sqlite[S5]: database is locked svn: E200042: Additional errors: svn: E200033: sqlite[S5]: database is locked svn: E200030: sqlite[S1]: cannot start a transaction within a transaction svn: E200030: sqlite[S1]: cannot start a transaction within a transaction ]]] To be clear: the "working copy database" is an sqlite database in the "wc.db" file inside the .svn directory at the root of your working copy. I'm not sure what else to suggest, but "something" is preventing 'svn' from locking its database; and since you're using a local disk, it seems to me that "network" is not involved in this locking process. BTW, what version of SVN are you using? -- Johan
RE: EXTERNAL: Re: svn version 1.10 lack of robustness in presence of flaky network
Reply below: -Original Message- From: Johan Corveleyn Sent: 24 April 2019 11:30 To: Marlow, Andrew Cc: users@subversion.apache.org Subject: Re: EXTERNAL: Re: svn version 1.10 lack of robustness in presence of flaky network > >Regarding the comment that was made, I don't know exactly how the svn repo > >is hosted in the corporate environment I am in. It is accessed via an http > >URL (not https, I know). The underlying filesystem is Windows because every > >now and then we get aggro due to the case preserving behaviour of the > >Windows filesystem. But is it on a network share? Not sure, but I don't > >think so. IMO that would be an extremely bad setup. >>The network share Stefan and I are referring to is not on the server side >>(which is accessed via https, that's fine; and >> we're not concerned with how that server is set up). We're talking about the >> client-side location where you're putting your working copy. [snip] Yes, thanks for clearing that point up. > Where are you checking out your software? Is it on a local disk? Yes. >Or on a CIFS mounted filesystem (Windows) No. > or on an NFS-mounted filesystem, or SMB, ... if you're on Solaris? No. > If in step 2 you're indeed using some network share as the location for your > working copy, that could be problematic. Indeed, especially with the network I am using. > As Stefan said, this is discouraged, and you should try to put working copies > on local disks. Good job I'm not, then. -- Johan The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. FIS is a trading name of the following companies: Fidelity Information Services Ltd (registered in England No.02225203), FIS Payments (UK) Ltd (No.04215488), FIS Asiapacrim Holdings Ltd (No.06707320), Certegy Card Services Ltd (No.03517639) and Efunds International Ltd (No.01930117), all with their registered office at Floor 1, 51/53 Hagley Road, Birmingham B16 8TU, United Kingdom; and FIS Payments (Ireland) Ltd (registered in Ireland No.126879), with its registered office at 25/28 North Wall Quay, Dublin 1, D01 H104, Ireland. FIS Payments (UK) Ltd is authorised and regulated by the Financial Conduct Authority; some services are covered by the Financial Ombudsman Service (in the UK). Calls to and from the companies may be recorded for quality purposes. All of the above companies are part of FIS (Fidelity National Information Services Inc.).
Re: EXTERNAL: Re: svn version 1.10 lack of robustness in presence of flaky network
On Wed, Apr 24, 2019 at 11:51 AM Marlow, Andrew wrote: > > Sorry everyone, I mis-spoke below. While looking at this issue I was also > filing a bug report on the maven jar signing plugin, which also has a problem > when the network is flaky. That is the thing that was calling out to the > timestamp server, not svn. I got mixed up, sorry. > > Regarding the comment that was made, I don't know exactly how the svn repo is > hosted in the corporate environment I am in. It is accessed via an http URL > (not https, I know). The underlying filesystem is Windows because every now > and then we get aggro due to the case preserving behaviour of the Windows > filesystem. But is it on a network share? Not sure, but I don't think so. IMO > that would be an extremely bad setup. > The network share Stefan and I are referring to is not on the server side (which is accessed via https, that's fine; and we're not concerned with how that server is set up). We're talking about the client-side location where you're putting your working copy. I'm not sure you fully understand the difference between "repository" (server-side, single source of truth of the entire history) and "working copy" (client-side checkout, where you perform local work to perform commits from, and "update" to get other's changes). See [1] for some more explanation. Where are you checking out your software? Is it on a local disk? Or on a CIFS mounted filesystem (Windows) or on an NFS-mounted filesystem, or SMB, ... if you're on Solaris? For example, are you doing the following? 1) Log into your Windows pc. 2) cd \\some\network\share (or cd M:\subdir; where M: is a mapped network drive) <- this is where you're putting your working copy 3) svn checkout https://svnserver.example.com/path/to/repo <- this is the URL to the repository, which can be hosted on Windows, Solaris, Linux, ... whatever If in step 2 you're indeed using some network share as the location for your working copy, that could be problematic. As Stefan said, this is discouraged, and you should try to put working copies on local disks. And if you really must work with networked filesystems for your working copy, you should look at the configuration options in the [working-copy] section of the client-side configuration file "config" (see [2] for some general information about the client-side config files). Maybe some tweaks there can help. [1] http://svnbook.red-bean.com/nightly/en/svn.basic.version-control-basics.html [2] http://svnbook.red-bean.com/nightly/en/svn.advanced.confarea.html -- Johan
RE: EXTERNAL: Re: svn version 1.10 lack of robustness in presence of flaky network
Sorry everyone, I mis-spoke below. While looking at this issue I was also filing a bug report on the maven jar signing plugin, which also has a problem when the network is flaky. That is the thing that was calling out to the timestamp server, not svn. I got mixed up, sorry. Regarding the comment that was made, I don't know exactly how the svn repo is hosted in the corporate environment I am in. It is accessed via an http URL (not https, I know). The underlying filesystem is Windows because every now and then we get aggro due to the case preserving behaviour of the Windows filesystem. But is it on a network share? Not sure, but I don't think so. IMO that would be an extremely bad setup. -Original Message- From: Marlow, Andrew Sent: 24 April 2019 09:52 To: users@subversion.apache.org Subject: RE: EXTERNAL: Re: svn version 1.10 lack of robustness in presence of flaky network Reply below: -Original Message- From: Stefan Sperling Sent: 24 April 2019 07:54 To: Marlow, Andrew Cc: Johan Corveleyn ; users@subversion.apache.org Subject: EXTERNAL: Re: svn version 1.10 lack of robustness in presence of flaky network On Wed, Apr 24, 2019 at 12:55:47AM +0200, Johan Corveleyn wrote: > On Mon, Apr 22, 2019 at 9:22 AM Marlow, Andrew > wrote: > > Hello everyone, > > I got this error below during an svn co command. It left my workspace in a > > bad state from which I had to do svn cleanup before trying again (the retry > > worked): [snip] > > I think this happens when the network is flaky. This error happened on > > windows but I have also seen it happen on solaris 10. Has anyone else seen > > this? If it is due to network flakiness then perhaps svn should retry to > > work around this transparently, and thus be more robust? Perhaps it could > > retry up to 3 times with a sleep a 1 second between retries? > > Is your working copy on a network filesystem (CIFS, NFS, ...)? [snip] While working copies on networks filesystems should generally work, such use is strongly discouraged. [snip] No. There is no network filesystem (CIFS) here. What about when I am using solaris? That's proof that it cannot be due to CIFS. The internet is being used because that it is where the timestamp server is. When the code tries to call out to that timeserver it has to travel via the corporate network, including navigating via the internet proxy. This network call fails randomly due a flaky network. The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. FIS is a trading name of the following companies: Fidelity Information Services Ltd (registered in England No.02225203), FIS Payments (UK) Ltd (No.04215488), FIS Asiapacrim Holdings Ltd (No.06707320), Certegy Card Services Ltd (No.03517639) and Efunds International Ltd (No.01930117), all with their registered office at Floor 1, 51/53 Hagley Road, Birmingham B16 8TU, United Kingdom; and FIS Payments (Ireland) Ltd (registered in Ireland No.126879), with its registered office at 25/28 North Wall Quay, Dublin 1, D01 H104, Ireland. FIS Payments (UK) Ltd is authorised and regulated by the Financial Conduct Authority; some services are covered by the Financial Ombudsman Service (in the UK). Calls to and from the companies may be recorded for quality purposes. All of the above companies are part of FIS (Fidelity National Information Services Inc.). The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. FIS is a trading name of the following companies: Fidelity Information Services Ltd (registered in England No.02225203), FIS Payments (UK) Ltd (No.04215488), FIS Asiapacrim Holdings Ltd (No.06707320), Certegy Card Services Ltd (No.03517639) and Efunds International Ltd (No.01930117), all with their registered office at Floor 1, 51/53 Hagley Road, Birmingham B16 8TU, United Kingdom; and FIS Payments (Ireland) Ltd (registered in Ireland No.126879), with its registered office at 25/28 North Wall Quay, Dublin 1, D01 H104, Ireland. FIS Payments (UK) Ltd is authorised and regulated by the Financial Conduct Authority; some services are covered by the Financial Ombudsman Service (in the UK). Calls to and from the companies may be recorded for quality purposes. All of the above companies are part of FIS (Fidelity
RE: EXTERNAL: Re: svn version 1.10 lack of robustness in presence of flaky network
Reply below: -Original Message- From: Stefan Sperling Sent: 24 April 2019 07:54 To: Marlow, Andrew Cc: Johan Corveleyn ; users@subversion.apache.org Subject: EXTERNAL: Re: svn version 1.10 lack of robustness in presence of flaky network On Wed, Apr 24, 2019 at 12:55:47AM +0200, Johan Corveleyn wrote: > On Mon, Apr 22, 2019 at 9:22 AM Marlow, Andrew > wrote: > > Hello everyone, > > I got this error below during an svn co command. It left my workspace in a > > bad state from which I had to do svn cleanup before trying again (the retry > > worked): [snip] > > I think this happens when the network is flaky. This error happened on > > windows but I have also seen it happen on solaris 10. Has anyone else seen > > this? If it is due to network flakiness then perhaps svn should retry to > > work around this transparently, and thus be more robust? Perhaps it could > > retry up to 3 times with a sleep a 1 second between retries? > > Is your working copy on a network filesystem (CIFS, NFS, ...)? [snip] While working copies on networks filesystems should generally work, such use is strongly discouraged. [snip] No. There is no network filesystem (CIFS) here. What about when I am using solaris? That's proof that it cannot be due to CIFS. The internet is being used because that it is where the timestamp server is. When the code tries to call out to that timeserver it has to travel via the corporate network, including navigating via the internet proxy. This network call fails randomly due a flaky network. The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. FIS is a trading name of the following companies: Fidelity Information Services Ltd (registered in England No.02225203), FIS Payments (UK) Ltd (No.04215488), FIS Asiapacrim Holdings Ltd (No.06707320), Certegy Card Services Ltd (No.03517639) and Efunds International Ltd (No.01930117), all with their registered office at Floor 1, 51/53 Hagley Road, Birmingham B16 8TU, United Kingdom; and FIS Payments (Ireland) Ltd (registered in Ireland No.126879), with its registered office at 25/28 North Wall Quay, Dublin 1, D01 H104, Ireland. FIS Payments (UK) Ltd is authorised and regulated by the Financial Conduct Authority; some services are covered by the Financial Ombudsman Service (in the UK). Calls to and from the companies may be recorded for quality purposes. All of the above companies are part of FIS (Fidelity National Information Services Inc.).
Re: svn version 1.10 lack of robustness in presence of flaky network
On Wed, Apr 24, 2019 at 12:55:47AM +0200, Johan Corveleyn wrote: > On Mon, Apr 22, 2019 at 9:22 AM Marlow, Andrew > wrote: > > Hello everyone, > > > > I got this error below during an svn co command. It left my workspace in a > > bad state from which I had to do svn cleanup before trying again (the retry > > worked): > > > > svn: E200033: Another process is blocking the working copy database, or the > > underlying filesystem does not support file locking; if the working copy is > > on a network filesystem, make sure file locking has been enabled on the > > file server > > svn: E200033: sqlite[S5]: database is locked > > svn: E200042: Additional errors: > > svn: E200033: sqlite[S5]: database is locked > > svn: E200030: sqlite[S1]: cannot start a transaction within a transaction > > svn: E200030: sqlite[S1]: cannot start a transaction within a transaction > > > > I think this happens when the network is flaky. This error happened on > > windows but I have also seen it happen on solaris 10. Has anyone else seen > > this? If it is due to network flakiness then perhaps svn should retry to > > work around this transparently, and thus be more robust? Perhaps it could > > retry up to 3 times with a sleep a 1 second between retries? > > > > Is your working copy on a network filesystem (CIFS, NFS, ...)? And are > you talking about a flaky network between your machine and its > networked filesystem? If so, I think there is not much we can do about > it ... the filesystem you're checking out to should reliable. There is > already a retry loop in some places for putting checked out files into > place, to work around locks from antivirus software etc, ... (but the > sqlite database itself should be reliably available). While working copies on networks filesystems should generally work, such use is strongly discouraged. So far, all reasons I've heard for putting working copies on network drives turned out to be backed by bad or misinformed decisions about the development process or allocation of hardware resources. Moving to local disks improved not just the SVN user experience but also repaired a broken process in such cases. So put working copies on a local disk, preferrably SSDs. Working copies should be considered temporary and disposable copies of your data. The repository on the server is the important and permanent database which must be protected and backed up, not the working copy. If your working copy is too large for a modern SSD (really?), consider sparse working copies (http://svnbook.red-bean.com/nightly/en/svn.advanced.sparsedirs.html) and/or reorganize your project such that parts of it can be checked out and built in isolation. That said, if you really must use a network filesystem, you should look into tweaking the following options in Subversion's 'config' file: ### Section for configuring working copies. [working-copy] ### Set to a list of the names of specific clients that should use ### exclusive SQLite locking of working copies. This increases the ### performance of the client but prevents concurrent access by ### other clients. Third-party clients may also support this ### option. ### Possible values: ### svn(the command line client) # exclusive-locking-clients = ### Set to true to enable exclusive SQLite locking of working ### copies by all clients using the 1.8 APIs. Enabling this may ### cause some clients to fail to work properly. This does not have ### to be set for exclusive-locking-clients to work. # exclusive-locking = false ### Set the SQLite busy timeout in milliseconds: the maximum time ### the client waits to get access to the SQLite database before ### returning an error. The default is 1, i.e. 10 seconds. ### Longer values may be useful when exclusive locking is enabled. # busy-timeout = 1
