You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(149) |
Jul
(77) |
Aug
(75) |
Sep
(181) |
Oct
(120) |
Nov
(109) |
Dec
(138) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
(37) |
Feb
(111) |
Mar
(115) |
Apr
(90) |
May
(135) |
Jun
(116) |
Jul
(93) |
Aug
(63) |
Sep
(73) |
Oct
(100) |
Nov
(145) |
Dec
(90) |
2006 |
Jan
(54) |
Feb
(79) |
Mar
(159) |
Apr
(70) |
May
(55) |
Jun
(92) |
Jul
(33) |
Aug
(70) |
Sep
(68) |
Oct
(107) |
Nov
(34) |
Dec
|
2007 |
Jan
|
Feb
(76) |
Mar
(96) |
Apr
(126) |
May
(107) |
Jun
(90) |
Jul
(95) |
Aug
(94) |
Sep
(159) |
Oct
(143) |
Nov
(114) |
Dec
(46) |
2008 |
Jan
(110) |
Feb
(62) |
Mar
(81) |
Apr
(101) |
May
(49) |
Jun
(100) |
Jul
(112) |
Aug
(102) |
Sep
(88) |
Oct
(72) |
Nov
(121) |
Dec
(79) |
2009 |
Jan
(50) |
Feb
(93) |
Mar
(139) |
Apr
(110) |
May
(122) |
Jun
(114) |
Jul
(149) |
Aug
(117) |
Sep
(96) |
Oct
(118) |
Nov
(112) |
Dec
(25) |
2010 |
Jan
(45) |
Feb
(206) |
Mar
(123) |
Apr
(147) |
May
(121) |
Jun
(68) |
Jul
(84) |
Aug
(77) |
Sep
(50) |
Oct
(34) |
Nov
(49) |
Dec
(31) |
2011 |
Jan
(65) |
Feb
(74) |
Mar
(72) |
Apr
(62) |
May
(50) |
Jun
(25) |
Jul
(47) |
Aug
(43) |
Sep
(35) |
Oct
(58) |
Nov
(90) |
Dec
(67) |
2012 |
Jan
(82) |
Feb
(44) |
Mar
(95) |
Apr
(60) |
May
(77) |
Jun
(118) |
Jul
(53) |
Aug
(14) |
Sep
(88) |
Oct
(41) |
Nov
(53) |
Dec
(37) |
2013 |
Jan
(48) |
Feb
(66) |
Mar
|
Apr
(54) |
May
(50) |
Jun
(7) |
Jul
(7) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2014 |
Jan
|
Feb
(64) |
Mar
(67) |
Apr
(40) |
May
(72) |
Jun
(42) |
Jul
(99) |
Aug
(40) |
Sep
(8) |
Oct
(3) |
Nov
(16) |
Dec
(10) |
2015 |
Jan
(9) |
Feb
(8) |
Mar
(10) |
Apr
(14) |
May
(27) |
Jun
(12) |
Jul
(38) |
Aug
(55) |
Sep
(27) |
Oct
(43) |
Nov
(11) |
Dec
(46) |
2016 |
Jan
(46) |
Feb
(37) |
Mar
(24) |
Apr
(3) |
May
(16) |
Jun
(17) |
Jul
(49) |
Aug
(7) |
Sep
|
Oct
(61) |
Nov
(11) |
Dec
(17) |
2017 |
Jan
(13) |
Feb
(12) |
Mar
(29) |
Apr
(5) |
May
(67) |
Jun
(21) |
Jul
(61) |
Aug
(6) |
Sep
|
Oct
|
Nov
|
Dec
|
From: Mantis B. T. <no...@bu...> - 2017-08-02 14:19:07
|
The following issue has been SUBMITTED. ====================================================================== http://bugs.bacula.org/view.php?id=2302 ====================================================================== Reported By: Phil Stracchino Assigned To: ====================================================================== Project: Bacula Bug Reports Issue ID: 2302 Category: other Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2017-08-02 15:18 BST Last Modified: 2017-08-02 15:18 BST ====================================================================== Summary: Release 9.0.3 (and older) : Catalog schema is not clean for use with MySQL 5.7/MariaDB 10.2 Description: MySQL 5.7, Percona Server 5.7, and MariaDB 10.2 are more strict than past branches about enforcing strict compliance with SQL standards, upon which MySQL has historically been rather lax. The Bacula catalog schema is not compliant with MySQL 5.7 because it contains SQL errors which older MySQL branches allowed to slide by. Most of these take the form of columns declared NOT NULL without a DEFAULT. This is a particular problem with DATETIME fields, because in addition to requiring a DEFAULT for DATETIME fields declared NOT NULL, out-of-the-box MySQL 5.7 requires that the DEFAULT value be a properly valid DATETIME string — which is to say it may not be just 0 and may not contain zero date parts, because there is no year 0, month 0 or day 0 in the calendar. The canonical correct DATETIME default is the Unix epoch, 1970-01-01 00:00:00. However, this will not work with Bacula code; in particular, it breaks Volume Use Duration windows. By changing MySQL 5.7's SQL_MODE variable to a mode that DOES NOT include the restrictions NO_ZERO_DATE and NO_ZERO_IN_DATE, it is possible to use 0000-00-00 00:00:00 as a DATETIME default. This default does not cause problems in Bacula's code. STRICT_ALL_TABLES can still be used as long as NO_ZERO_DATE and NO_ZERO_IN_DATE are turned off. If SQL_MODE is modified in this manner and all DATETIME fields are changed to DEFAULT '0000-00-00 00:00:00', the schema will work against MySQL/Percona Server 5.7 and MariaDB 10.2 and Bacula displays no behavioral or functional problems. This change has no impact on MySQL branches prior to 5.7. Steps to Reproduce: Any attempt to perform any Bacula operation against a MySQL 5.7-or-equivalent backing database that updates the Catalog, without first patching the Catalog tables as described above, will fail. Additional Information: This is not a case of SQL syntax which "used to be right and is now wrong". NOT NULL with no DEFAULT, or 0 as a DATETIME value, have *always* been wrong. It's just that in the past, MySQL allowed you to get away with it, and from 5.7 onwards, by default it doesn't let you get away with it any more. The problem of NOT NULL without DEFAULT of course is that if you fail to supply a value for a column declared NOT NULL, but no DEFAULT is specified, you have told MySQL that it is not allowed to leave the column empty, it MUST fill in a value — but you haven't told it what value it can use. (Side note: I once saw a customer crash MySQL by defining a column NOT NULL DEFAULT NULL ...) ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2017-08-02 15:18 Phil StracchinoNew Issue ====================================================================== |
From: Mantis B. T. <no...@bu...> - 2017-08-02 12:43:24
|
A NOTE has been added to this issue. ---------------------------------------------------------------------- (0007599) Phil Stracchino (reporter) - 2017-08-02 13:43 http://bugs.bacula.org/view.php?id=2300#c7599 ---------------------------------------------------------------------- Also, correction to the original description: The Director DOES connect to the SD on mount/unmount, but the SD never shows any sign of having received the mount/umount command. ---------------------------------------------------------------------- |
From: Mantis B. T. <no...@bu...> - 2017-08-02 12:37:38
|
A NOTE has been added to this issue. ---------------------------------------------------------------------- (0007598) Phil Stracchino (reporter) - 2017-08-02 13:37 http://bugs.bacula.org/view.php?id=2300#c7598 ---------------------------------------------------------------------- As suggested by Martin Simmons, mount and unmount work as long as slot=0 is specified. It appears the slot argument is now MANDATORY and the mount/unmount command is not properly sent to the SD without it. ---------------------------------------------------------------------- |
From: Mantis B. T. <no...@bu...> - 2017-08-02 01:07:44
|
The following issue has been SUBMITTED. ====================================================================== http://bugs.bacula.org/view.php?id=2301 ====================================================================== Reported By: Phil Stracchino Assigned To: ====================================================================== Project: Bacula Bug Reports Issue ID: 2301 Category: Storage Daemon Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2017-08-02 02:07 BST Last Modified: 2017-08-02 02:07 BST ====================================================================== Summary: Release 9.0.3 : Storage daemon reports free space incorrectly on Solaris 11 Description: A disk storage daemon running on Solaris 11.3, with its storage on an 11TB ZFS pool with roughly 4.1TB available, reports available space a 1.131 PB. Steps to Reproduce: You kinda need to have Solaris 11, I guess... ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2017-08-02 02:07 Phil StracchinoNew Issue ====================================================================== |
From: Mantis B. T. <no...@bu...> - 2017-08-01 22:11:29
|
The following issue has been SUBMITTED. ====================================================================== http://bugs.bacula.org/view.php?id=2300 ====================================================================== Reported By: Phil Stracchino Assigned To: ====================================================================== Project: Bacula Bug Reports Issue ID: 2300 Category: Storage Daemon Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2017-08-01 23:11 BST Last Modified: 2017-08-01 23:11 BST ====================================================================== Summary: Release 9.0.3 : Cannot mount or unmount tapes on standalone tape drives Description: Mounting and unmounting tapes in a standalone tape drive does not work in 9.0.3. Tapes can be mounted only by setting Automount=yes and loading the tape before starting the storage daemon. Tapes can be unmounted only by stopping the storage daemon and using mt. Needless to say, this makes jobs that require more than one tape impossible. Reading and writing to a mounted tape works normally. It is possible to PARTIALLY work around this by setting up a fake autochanger with a single Drive. This makes it possible to mount tapes, but they still cannot be unmounted. Study of traffic between the Director and Storage at -d 200 reveals that the Director appears to try to SEND the mount/umount command, but does not open a connection to the Storage daemon first, and so the Storage daemon never receives it. Steps to Reproduce: Set up a standalone tape drive. Run Director and SD at -d 200. Try to mount or unmount a tape. Observe a complete lack of anything happening on the storage daemon, which apparently never receives the command. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2017-08-01 23:11 Phil StracchinoNew Issue ====================================================================== |
From: Mantis B. T. <no...@bu...> - 2017-08-01 21:59:52
|
The following issue has been SUBMITTED. ====================================================================== http://bugs.bacula.org/view.php?id=2299 ====================================================================== Reported By: Phil Stracchino Assigned To: ====================================================================== Project: Bacula Bug Reports Issue ID: 2299 Category: Director Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2017-08-01 22:59 BST Last Modified: 2017-08-01 22:59 BST ====================================================================== Summary: Release 9.0.3 : Database write batch size code does not work (and is set to wrong value anyway) Description: The Director contains code to batch attribute writes into chunks throughout the job instead of writing them all at the end. However, this code demonstrably does not work. By modifying the code for testing purposes to make the batch table a global table instead of a thread-private temporary table, it is possible to see that the batch table grows monotonically throughout the job until the very end of the job, and is then all spooled into the database in one massive blast that may be millions of rows on a large backup. In most cases, this merely causes a performance problem as Bacula hammers the database at the end of each job. However, when Bacula is running against a MySQL-alike database with Galera synchronous clustering, because the batching does not work, any job that backs up more than 128K files will fail with a wsrep_max_ws_rows exceeded error. It is reasonable to expect that it may also cause similar failures when running against Oracle MySQL 5.7's Group Replication feature, as Group Replication is Oracle's fairly blatant attempt to copy Galera's functionality. This is not a new bug; I don't know when this batch size limit code was added, but watching DB usage patterns across multiple Bacula releases makes it clear that it has never worked. Steps to Reproduce: Method 1: Run Bacula against a Galera cluster (MariaDB + Galera or Percona XtraDB Cluster). Observe that all jobs over 128k files fail at the end of the job with 'wsrep_max_ws_rows exceeded'. The failure point can be moved by changing wsrep_max_ws_rows, but this variable cannot be increased indefinitely. Method 2: Change the hardcoded batch limit from 500000 to 25000, 10000, even 1000, and recompile. Observe that the behavior does not change, and jobs against Galera clusters still fail at 128K files. Method 3: monitor any database during a job and observe that no attribute inserts take place until right at the end of the job after data writing is complete. Method 4: monitor the batch table by any means during a job and observe that rather than repeatedly growing and being flushed, it grows monotonically until the end of the job, when it is all dumped into the DB at once. Additional Information: >From discussions with Kern, the batch size limit was SUPPOSED to be set to 25000. It is actually set to 500,000. However, this is moot because it doesn't work anyway. The ideal would be if this were made a Director configuration tunable (MaxBatchSize, say) defaulting to 25000, to enable ANYONE to tune it to whatever value they found performed best with *their* backing database. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2017-08-01 22:59 Phil StracchinoNew Issue ====================================================================== |
From: Mantis B. T. <no...@bu...> - 2017-07-31 05:17:30
|
A NOTE has been added to this issue. ---------------------------------------------------------------------- (0007597) TomJBE (reporter) - 2017-07-31 06:17 http://bugs.bacula.org/view.php?id=2295#c7597 ---------------------------------------------------------------------- Same problem here on Gentoo Linux. Seems the new acl code introduced in version 7.4.5 does not respect the --enable/disable-acl switch anymore. Any time you try a './configure --enable-client-only --disable-acl' leads to the above mentioned error no matter which database you use and no matter if the ACL libraries are installed. ---------------------------------------------------------------------- |
From: Mantis B. T. <no...@bu...> - 2017-07-26 12:38:33
|
A NOTE has been added to this issue. ---------------------------------------------------------------------- (0007596) wandihuttel (reporter) - 2017-07-26 09:38 http://bugs.bacula.org/view.php?id=2249#c7596 ---------------------------------------------------------------------- Hello Kern I don't know if was correct, but if the RunTime is equal 0, kbps shouldn't have 0 too? And If RunTime is greater than 0, kbps should have some value greater than 0? In backup.c there isn't this check about kbps less than 0.05 Sorry if I'm wrong and do what is the correct. --------------------------------------------------------------- original restore.c RunTime = jcr->jr.EndTime - jcr->jr.StartTime; if (RunTime <= 0) { RunTime = 1; } kbps = (double)jcr->jr.JobBytes / (1000.0 * (double)RunTime); if (kbps < 0.05) { kbps = 0; } --------------------------------------------------------------- original backup.c RunTime = jcr->jr.EndTime - jcr->jr.StartTime; if (RunTime <= 0) { RunTime = 1; } kbps = ((double)jcr->jr.JobBytes) / (1000.0 * (double)RunTime); --------------------------------------------------------------- restore.c.patch RunTime = jcr->jr.EndTime - jcr->jr.StartTime; if (RunTime <= 0) { RunTime = 1; kbps = 0; } else { kbps = (double)jcr->jr.JobBytes / (1000.0 * (double)RunTime); } ---------------------------------------------------------------------- |
From: Mantis B. T. <no...@bu...> - 2017-07-26 11:36:46
|
The following issue requires your FEEDBACK. ====================================================================== http://bugs.bacula.org/view.php?id=2249 ====================================================================== Reported By: wandihuttel Assigned To: kern ====================================================================== Project: Bacula Bug Reports Issue ID: 2249 Category: bconsole Reproducibility: always Severity: minor Priority: normal Status: feedback ====================================================================== Date Submitted: 2016-10-03 14:34 BST Last Modified: 2017-07-26 12:36 BST ====================================================================== Summary: [PATCH] Include elapsed time in restore and verify jobs in JobLog Description: I'm submiting a patch to include Elapsed Time in "restore" and "verify" jobs. In restore Jobs I've modified "Bytes Restored" to show bytes in human_readable format, using the function (edit_uint64_with_suffix) like backup.c ====================================================================== ---------------------------------------------------------------------- (0007577) wandihuttel (reporter) - 2017-07-13 17:38 http://bugs.bacula.org/view.php?id=2249#c7577 ---------------------------------------------------------------------- Hello I'm attaching the patches for the 9.0.1 version. ---------------------------------------------------------------------- (0007590) kern (administrator) - 2017-07-23 09:45 http://bugs.bacula.org/view.php?id=2249#c7590 ---------------------------------------------------------------------- These patches do not apply. Please use the repo and git to produce them. ---------------------------------------------------------------------- (0007593) wandihuttel (reporter) - 2017-07-25 21:14 http://bugs.bacula.org/view.php?id=2249#c7593 ---------------------------------------------------------------------- Hello Following the patches using git. ---------------------------------------------------------------------- (0007594) kern (administrator) - 2017-07-26 12:24 http://bugs.bacula.org/view.php?id=2249#c7594 ---------------------------------------------------------------------- Thanks. I confirm that they apply perfectly. I will look at them this afternoon and then commit them. Thanks for the patches. I will let you know shortly. ---------------------------------------------------------------------- (0007595) kern (administrator) - 2017-07-26 12:36 http://bugs.bacula.org/view.php?id=2249#c7595 ---------------------------------------------------------------------- I notice you have changed the calculation of kbps in the restore.c patch. If there was a reason, please let me know, otherwise the original logic in the calculation was correct and I will put it back. Issue History Date Modified Username Field Change ====================================================================== 2016-10-03 14:34 wandihuttel New Issue 2016-10-03 14:34 wandihuttel File Added: restore.c.patch 2016-10-03 14:36 wandihuttel File Added: verify.c.patch 2016-10-14 17:06 kern Assigned To => kern 2016-10-14 17:06 kern Status new => acknowledged 2016-10-14 17:06 kern Summary Include elapsed time in restore and verify jobs in JobLog => [PATCH] Include elapsed time in restore and verify jobs in JobLog 2017-07-13 17:38 wandihuttel File Added: restore-9.0.1.c.patch 2017-07-13 17:38 wandihuttel File Added: verify-9.0.1.c.patch 2017-07-13 17:38 wandihuttel Note Added: 0007577 2017-07-23 09:45 kern Status acknowledged => feedback 2017-07-23 09:45 kern Note Added: 0007590 2017-07-25 21:14 wandihuttel File Added: verify-9.0.2.patch 2017-07-25 21:14 wandihuttel File Added: restore-9.0.2.patch 2017-07-25 21:14 wandihuttel Note Added: 0007593 2017-07-25 21:14 wandihuttel Status feedback => assigned 2017-07-26 12:24 kern Note Added: 0007594 2017-07-26 12:36 kern Status assigned => feedback 2017-07-26 12:36 kern Note Added: 0007595 ====================================================================== |
From: Mantis B. T. <no...@bu...> - 2017-07-26 11:24:54
|
A NOTE has been added to this issue. ---------------------------------------------------------------------- (0007594) kern (administrator) - 2017-07-26 12:24 http://bugs.bacula.org/view.php?id=2249#c7594 ---------------------------------------------------------------------- Thanks. I confirm that they apply perfectly. I will look at them this afternoon and then commit them. Thanks for the patches. I will let you know shortly. ---------------------------------------------------------------------- |
From: Mantis B. T. <no...@bu...> - 2017-07-25 20:14:47
|
A NOTE has been added to this issue. ---------------------------------------------------------------------- (0007593) wandihuttel (reporter) - 2017-07-25 17:14 http://bugs.bacula.org/view.php?id=2249#c7593 ---------------------------------------------------------------------- Hello Following the patches using git. ---------------------------------------------------------------------- Attached Files: - verify-9.0.2.patch (2,057 bytes) - restore-9.0.2.patch (1,913 bytes) ---------------------------------------------------------------------- |
From: Mantis B. T. <no...@bu...> - 2017-07-25 09:36:55
|
The following issue has been CLOSED ====================================================================== http://bugs.bacula.org/view.php?id=2298 ====================================================================== Reported By: agreenblatt Assigned To: ====================================================================== Project: Bacula Bug Reports Issue ID: 2298 Category: btape Reproducibility: always Severity: minor Priority: normal Status: closed Resolution: fixed Fixed in Version: 9.0.2 ====================================================================== Date Submitted: 2017-07-25 01:04 BST Last Modified: 2017-07-25 10:36 BST ====================================================================== Summary: Btape Test - Append Files Test Description: BTape test append files test fails on Bacula 9.0.0 and 9.0.1 System: Debian 8.8 (kernel 3.16.0-4-amd64), various ATTO SAS HBAs, HP LTO 6 tape drive Btape test works properly under Bacula 7.4.7. root@tapebackup:/usr/local/bacula/etc# btape -c bacula-sd.conf /dev/nst0 Tape block granularity is 1024 bytes. 20-Jul 03:11 btape JobId 0: Warning: Failed to find any plugins in /usr/local/lib btape: butil.c:290-0 Using device: "/dev/nst0" for writing. btape: btape.c:478-0 open device "LTO-6" (/dev/nst0): OK *test === Write, rewind, and re-read test === I'm going to write 10000 records and an EOF then write 10000 records and an EOF, then rewind, and re-read the data to verify that it is correct. This is an *essential* feature ... btape: btape.c:1161-0 Wrote 10000 blocks of 64412 bytes. btape: btape.c:612-0 Wrote 1 EOF to "LTO-6" (/dev/nst0) btape: btape.c:1177-0 Wrote 10000 blocks of 64412 bytes. btape: btape.c:612-0 Wrote 1 EOF to "LTO-6" (/dev/nst0) btape: btape.c:1219-0 Rewind OK. 10000 blocks re-read correctly. Got EOF on tape. 10000 blocks re-read correctly. === Test Succeeded. End Write, rewind, and re-read test === btape: btape.c:1286-0 Block position test btape: btape.c:1297-0 Rewind OK. Reposition to file:block 0:4 Block 5 re-read correctly. Reposition to file:block 0:200 Block 201 re-read correctly. Reposition to file:block 0:9999 Block 10000 re-read correctly. Reposition to file:block 1:0 Block 10001 re-read correctly. Reposition to file:block 1:600 Block 10601 re-read correctly. Reposition to file:block 1:9999 Block 20000 re-read correctly. === Test Succeeded. End Write, rewind, and re-read test === === Append files test === This test is essential to Bacula. I'm going to write one record in file 0, two records in file 1, and three records in file 2 btape: btape.c:582-0 Rewound "LTO-6" (/dev/nst0) btape: btape.c:1917-0 Wrote one record of 64412 bytes. btape: btape.c:1919-0 Wrote block to device. btape: btape.c:612-0 Wrote 1 EOF to "LTO-6" (/dev/nst0) btape: btape.c:1917-0 Wrote one record of 64412 bytes. btape: btape.c:1919-0 Wrote block to device. btape: btape.c:1917-0 Wrote one record of 64412 bytes. btape: btape.c:1919-0 Wrote block to device. btape: btape.c:612-0 Wrote 1 EOF to "LTO-6" (/dev/nst0) btape: btape.c:1917-0 Wrote one record of 64412 bytes. btape: btape.c:1919-0 Wrote block to device. btape: btape.c:1917-0 Wrote one record of 64412 bytes. btape: btape.c:1919-0 Wrote block to device. btape: btape.c:1917-0 Wrote one record of 64412 bytes. btape: btape.c:1919-0 Wrote block to device. btape: btape.c:612-0 Wrote 1 EOF to "LTO-6" (/dev/nst0) btape: btape.c:478-0 open device "LTO-6" (/dev/nst0): OK btape: btape.c:582-0 Rewound "LTO-6" (/dev/nst0) btape: btape.c:1430-0 Now moving to end of medium. btape: btape.c:633-0 Moved to end of medium. We should be in file 3. I am at file 3. This is correct! Now the important part, I am going to attempt to append to the tape. btape: btape.c:1917-0 Wrote one record of 64412 bytes. btape: btape.c:1919-0 Wrote block to device. btape: btape.c:612-0 Wrote 1 EOF to "LTO-6" (/dev/nst0) btape: btape.c:582-0 Rewound "LTO-6" (/dev/nst0) Done appending, there should be no I/O errors Doing Bacula scan of blocks: 1 block of 64448 bytes in file 1 End of File mark. 2 blocks of 64448 bytes in file 2 End of File mark. 3 blocks of 64448 bytes in file 3 End of File mark. 1 block of 64448 bytes in file 4 End of File mark. Total files=5, blocks=7, bytes = 451,136 End scanning the tape. We should be in file 4. I am at file 5. This is NOT correct!!!! The above Bacula scan should have output identical to what follows. Please double check it ... === Sample correct output === 1 block of 64448 bytes in file 1 End of File mark. 2 blocks of 64448 bytes in file 2 End of File mark. 3 blocks of 64448 bytes in file 3 End of File mark. 1 block of 64448 bytes in file 4 End of File mark. Total files=4, blocks=7, bytes = 451,136 === End sample correct output === If the above scan output is not identical to the sample output, you MUST correct the problem or Bacula will not be able to write multiple Jobs to the tape. === Forward space files test === This test is essential to Bacula. I'm going to write five files then test forward spacing btape: btape.c:582-0 Rewound "LTO-6" (/dev/nst0) btape: btape.c:1917-0 Wrote one record of 64412 bytes. btape: btape.c:1919-0 Wrote block to device. btape: btape.c:612-0 Wrote 1 EOF to "LTO-6" (/dev/nst0) btape: btape.c:1917-0 Wrote one record of 64412 bytes. btape: btape.c:1919-0 Wrote block to device. btape: btape.c:1917-0 Wrote one record of 64412 bytes. btape: btape.c:1919-0 Wrote block to device. btape: btape.c:612-0 Wrote 1 EOF to "LTO-6" (/dev/nst0) btape: btape.c:1917-0 Wrote one record of 64412 bytes. btape: btape.c:1919-0 Wrote block to device. btape: btape.c:1917-0 Wrote one record of 64412 bytes. btape: btape.c:1919-0 Wrote block to device. btape: btape.c:1917-0 Wrote one record of 64412 bytes. btape: btape.c:1919-0 Wrote block to device. btape: btape.c:612-0 Wrote 1 EOF to "LTO-6" (/dev/nst0) btape: btape.c:1917-0 Wrote one record of 64412 bytes. btape: btape.c:1919-0 Wrote block to device. btape: btape.c:1917-0 Wrote one record of 64412 bytes. btape: btape.c:1919-0 Wrote block to device. btape: btape.c:612-0 Wrote 1 EOF to "LTO-6" (/dev/nst0) btape: btape.c:1917-0 Wrote one record of 64412 bytes. btape: btape.c:1919-0 Wrote block to device. btape: btape.c:612-0 Wrote 1 EOF to "LTO-6" (/dev/nst0) btape: btape.c:582-0 Rewound "LTO-6" (/dev/nst0) btape: btape.c:1644-0 Now forward spacing 1 file. We should be in file 1. I am at file 1. This is correct! btape: btape.c:1656-0 Now forward spacing 2 files. We should be in file 3. I am at file 3. This is correct! btape: btape.c:582-0 Rewound "LTO-6" (/dev/nst0) btape: btape.c:1669-0 Now forward spacing 4 files. We should be in file 4. I am at file 4. This is correct! btape: btape.c:1687-0 Now forward spacing 1 more file. We should be in file 5. I am at file 5. This is correct! === End Forward space files test === * bacula-sd.conf (I tried this without the Hardware End of File line; same result): Device { Name = LTO-6 Media Type = LTO-6 Device Type = Tape Archive Device = /dev/nst0 AutomaticMount = yes; # when device opened, read it AlwaysOpen = yes; RemovableMedia = yes; RandomAccess = no; Maximum File Size = 5GB Hardware End of File = no } tapeinfo -f /dev/sg8 Product Type: Tape Drive Vendor ID: 'HP ' Product ID: 'Ultrium 6-SCSI ' Revision: '35GD' Attached Changer API: No SerialNumber: 'HUJ4321BY1' MinBlock: 1 MaxBlock: 16777215 SCSI ID: 0 SCSI LUN: 0 Ready: yes BufferedMode: yes Medium Type: Not Loaded Density Code: 0x5a BlockSize: 0 DataCompEnabled: yes DataCompCapable: yes DataDeCompEnabled: yes CompType: 0x1 DeCompType: 0x1 BOP: yes Block Position: 0 ActivePartition: 0 EarlyWarningSize: 0 NumPartitions: 0 MaxPartitions: 3 Steps to Reproduce: Install Bacula. Run btape test. Additional Information: >From Jim Richardson: Be sure to factory default your tape drive. I had the exact issue with my LTO7. The drive was used in a non-linux environment before. My steps to factory reset are a pain, but they got me working. Yours may be different. Manufacturer dependent. # Steps 1. Install non-RAID HBA 2. install lin_tape & lin_taped 3. install ITDT 4. run full set of tests in ITDT 5. factory default settings - Specifically the "Read Past Filemark" setting MUST BE no http://www-01.ibm.com/support/docview.wss?uid=ssg1S7002972&aid=1 6. remove lin_tape & lin_taped 7. rmmod st 8. modprob st 9. power cycle library 10. Bacula configuration 11. btape test # tapeinfo -f /dev/nst0 Product Type: Tape Drive Vendor ID: 'IBM ' Product ID: 'ULT3580-HH7 ' Revision: 'G9Q1' Attached Changer API: No SerialNumber: '1097000515' MinBlock: 1 MaxBlock: 8388608 SCSI ID: 1 SCSI LUN: 0 Ready: yes BufferedMode: yes Medium Type: 0x78 Density Code: 0x5c BlockSize: 0 DataCompEnabled: yes DataCompCapable: yes DataDeCompEnabled: yes CompType: 0xff DeCompType: 0xff BOP: yes Block Position: 0 Partition 0 Remaining Kbytes: -1 Partition 0 Size in Kbytes: -1 ActivePartition: 0 EarlyWarningSize: 0 NumPartitions: 0 MaxPartitions: 3 # lsscsi -g [3:0:1:0] tape IBM ULT3580-HH7 G9Q1 /dev/st0 /dev/sg5 [3:0:1:1] mediumx IBM 3572-TL 0071 - /dev/sg6 Device { Name = Drive-1 # Drive Index = 0 Media Type = LTO-7 Archive Device = /dev/nst0 AutomaticMount = yes; # when device opened, read it AlwaysOpen = yes; RemovableMedia = yes; RandomAccess = no; AutoChanger = yes Alert Command = "sh -c 'tapeinfo -f %c |grep TapeAlert|cat'" } Jim Richardson Note: In HP Library and Tape Tools, Aaron could not find a similar setting for his LTO6 drive. ====================================================================== ---------------------------------------------------------------------- (0007592) kern (administrator) - 2017-07-25 10:36 http://bugs.bacula.org/view.php?id=2298#c7592 ---------------------------------------------------------------------- Thanks for submitting this bug report. I took a look at this problem over the weekend, and it seems that the regression test script that we have that should avoid this kind of regression did not carefully check the output. I have fixed that, and I also fixed the code that created the problem. The number of files is incremented when an EOF is read. When a second EOF is read, that signals EOT (end of tape or end of tape data), and it also incorrectly incremented the file count. Bottom line: this is fixed in version 9.0.2, which is now released to both Source Forge and to www.bacula.org Issue History Date Modified Username Field Change ====================================================================== 2017-07-25 01:04 agreenblatt New Issue 2017-07-25 10:36 kern Status new => closed 2017-07-25 10:36 kern Resolution open => fixed 2017-07-25 10:36 kern Fixed in Version => 9.0.2 2017-07-25 10:36 kern Note Added: 0007592 ====================================================================== |
From: Mantis B. T. <no...@bu...> - 2017-07-25 00:04:20
|
The following issue has been SUBMITTED. ====================================================================== http://bugs.bacula.org/view.php?id=2298 ====================================================================== Reported By: agreenblatt Assigned To: ====================================================================== Project: Bacula Bug Reports Issue ID: 2298 Category: btape Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2017-07-25 01:04 BST Last Modified: 2017-07-25 01:04 BST ====================================================================== Summary: Btape Test - Append Files Test Description: BTape test append files test fails on Bacula 9.0.0 and 9.0.1 System: Debian 8.8 (kernel 3.16.0-4-amd64), various ATTO SAS HBAs, HP LTO 6 tape drive Btape test works properly under Bacula 7.4.7. root@tapebackup:/usr/local/bacula/etc# btape -c bacula-sd.conf /dev/nst0 Tape block granularity is 1024 bytes. 20-Jul 03:11 btape JobId 0: Warning: Failed to find any plugins in /usr/local/lib btape: butil.c:290-0 Using device: "/dev/nst0" for writing. btape: btape.c:478-0 open device "LTO-6" (/dev/nst0): OK *test === Write, rewind, and re-read test === I'm going to write 10000 records and an EOF then write 10000 records and an EOF, then rewind, and re-read the data to verify that it is correct. This is an *essential* feature ... btape: btape.c:1161-0 Wrote 10000 blocks of 64412 bytes. btape: btape.c:612-0 Wrote 1 EOF to "LTO-6" (/dev/nst0) btape: btape.c:1177-0 Wrote 10000 blocks of 64412 bytes. btape: btape.c:612-0 Wrote 1 EOF to "LTO-6" (/dev/nst0) btape: btape.c:1219-0 Rewind OK. 10000 blocks re-read correctly. Got EOF on tape. 10000 blocks re-read correctly. === Test Succeeded. End Write, rewind, and re-read test === btape: btape.c:1286-0 Block position test btape: btape.c:1297-0 Rewind OK. Reposition to file:block 0:4 Block 5 re-read correctly. Reposition to file:block 0:200 Block 201 re-read correctly. Reposition to file:block 0:9999 Block 10000 re-read correctly. Reposition to file:block 1:0 Block 10001 re-read correctly. Reposition to file:block 1:600 Block 10601 re-read correctly. Reposition to file:block 1:9999 Block 20000 re-read correctly. === Test Succeeded. End Write, rewind, and re-read test === === Append files test === This test is essential to Bacula. I'm going to write one record in file 0, two records in file 1, and three records in file 2 btape: btape.c:582-0 Rewound "LTO-6" (/dev/nst0) btape: btape.c:1917-0 Wrote one record of 64412 bytes. btape: btape.c:1919-0 Wrote block to device. btape: btape.c:612-0 Wrote 1 EOF to "LTO-6" (/dev/nst0) btape: btape.c:1917-0 Wrote one record of 64412 bytes. btape: btape.c:1919-0 Wrote block to device. btape: btape.c:1917-0 Wrote one record of 64412 bytes. btape: btape.c:1919-0 Wrote block to device. btape: btape.c:612-0 Wrote 1 EOF to "LTO-6" (/dev/nst0) btape: btape.c:1917-0 Wrote one record of 64412 bytes. btape: btape.c:1919-0 Wrote block to device. btape: btape.c:1917-0 Wrote one record of 64412 bytes. btape: btape.c:1919-0 Wrote block to device. btape: btape.c:1917-0 Wrote one record of 64412 bytes. btape: btape.c:1919-0 Wrote block to device. btape: btape.c:612-0 Wrote 1 EOF to "LTO-6" (/dev/nst0) btape: btape.c:478-0 open device "LTO-6" (/dev/nst0): OK btape: btape.c:582-0 Rewound "LTO-6" (/dev/nst0) btape: btape.c:1430-0 Now moving to end of medium. btape: btape.c:633-0 Moved to end of medium. We should be in file 3. I am at file 3. This is correct! Now the important part, I am going to attempt to append to the tape. btape: btape.c:1917-0 Wrote one record of 64412 bytes. btape: btape.c:1919-0 Wrote block to device. btape: btape.c:612-0 Wrote 1 EOF to "LTO-6" (/dev/nst0) btape: btape.c:582-0 Rewound "LTO-6" (/dev/nst0) Done appending, there should be no I/O errors Doing Bacula scan of blocks: 1 block of 64448 bytes in file 1 End of File mark. 2 blocks of 64448 bytes in file 2 End of File mark. 3 blocks of 64448 bytes in file 3 End of File mark. 1 block of 64448 bytes in file 4 End of File mark. Total files=5, blocks=7, bytes = 451,136 End scanning the tape. We should be in file 4. I am at file 5. This is NOT correct!!!! The above Bacula scan should have output identical to what follows. Please double check it ... === Sample correct output === 1 block of 64448 bytes in file 1 End of File mark. 2 blocks of 64448 bytes in file 2 End of File mark. 3 blocks of 64448 bytes in file 3 End of File mark. 1 block of 64448 bytes in file 4 End of File mark. Total files=4, blocks=7, bytes = 451,136 === End sample correct output === If the above scan output is not identical to the sample output, you MUST correct the problem or Bacula will not be able to write multiple Jobs to the tape. === Forward space files test === This test is essential to Bacula. I'm going to write five files then test forward spacing btape: btape.c:582-0 Rewound "LTO-6" (/dev/nst0) btape: btape.c:1917-0 Wrote one record of 64412 bytes. btape: btape.c:1919-0 Wrote block to device. btape: btape.c:612-0 Wrote 1 EOF to "LTO-6" (/dev/nst0) btape: btape.c:1917-0 Wrote one record of 64412 bytes. btape: btape.c:1919-0 Wrote block to device. btape: btape.c:1917-0 Wrote one record of 64412 bytes. btape: btape.c:1919-0 Wrote block to device. btape: btape.c:612-0 Wrote 1 EOF to "LTO-6" (/dev/nst0) btape: btape.c:1917-0 Wrote one record of 64412 bytes. btape: btape.c:1919-0 Wrote block to device. btape: btape.c:1917-0 Wrote one record of 64412 bytes. btape: btape.c:1919-0 Wrote block to device. btape: btape.c:1917-0 Wrote one record of 64412 bytes. btape: btape.c:1919-0 Wrote block to device. btape: btape.c:612-0 Wrote 1 EOF to "LTO-6" (/dev/nst0) btape: btape.c:1917-0 Wrote one record of 64412 bytes. btape: btape.c:1919-0 Wrote block to device. btape: btape.c:1917-0 Wrote one record of 64412 bytes. btape: btape.c:1919-0 Wrote block to device. btape: btape.c:612-0 Wrote 1 EOF to "LTO-6" (/dev/nst0) btape: btape.c:1917-0 Wrote one record of 64412 bytes. btape: btape.c:1919-0 Wrote block to device. btape: btape.c:612-0 Wrote 1 EOF to "LTO-6" (/dev/nst0) btape: btape.c:582-0 Rewound "LTO-6" (/dev/nst0) btape: btape.c:1644-0 Now forward spacing 1 file. We should be in file 1. I am at file 1. This is correct! btape: btape.c:1656-0 Now forward spacing 2 files. We should be in file 3. I am at file 3. This is correct! btape: btape.c:582-0 Rewound "LTO-6" (/dev/nst0) btape: btape.c:1669-0 Now forward spacing 4 files. We should be in file 4. I am at file 4. This is correct! btape: btape.c:1687-0 Now forward spacing 1 more file. We should be in file 5. I am at file 5. This is correct! === End Forward space files test === * bacula-sd.conf (I tried this without the Hardware End of File line; same result): Device { Name = LTO-6 Media Type = LTO-6 Device Type = Tape Archive Device = /dev/nst0 AutomaticMount = yes; # when device opened, read it AlwaysOpen = yes; RemovableMedia = yes; RandomAccess = no; Maximum File Size = 5GB Hardware End of File = no } tapeinfo -f /dev/sg8 Product Type: Tape Drive Vendor ID: 'HP ' Product ID: 'Ultrium 6-SCSI ' Revision: '35GD' Attached Changer API: No SerialNumber: 'HUJ4321BY1' MinBlock: 1 MaxBlock: 16777215 SCSI ID: 0 SCSI LUN: 0 Ready: yes BufferedMode: yes Medium Type: Not Loaded Density Code: 0x5a BlockSize: 0 DataCompEnabled: yes DataCompCapable: yes DataDeCompEnabled: yes CompType: 0x1 DeCompType: 0x1 BOP: yes Block Position: 0 ActivePartition: 0 EarlyWarningSize: 0 NumPartitions: 0 MaxPartitions: 3 Steps to Reproduce: Install Bacula. Run btape test. Additional Information: >From Jim Richardson: Be sure to factory default your tape drive. I had the exact issue with my LTO7. The drive was used in a non-linux environment before. My steps to factory reset are a pain, but they got me working. Yours may be different. Manufacturer dependent. # Steps 1. Install non-RAID HBA 2. install lin_tape & lin_taped 3. install ITDT 4. run full set of tests in ITDT 5. factory default settings - Specifically the "Read Past Filemark" setting MUST BE no http://www-01.ibm.com/support/docview.wss?uid=ssg1S7002972&aid=1 6. remove lin_tape & lin_taped 7. rmmod st 8. modprob st 9. power cycle library 10. Bacula configuration 11. btape test # tapeinfo -f /dev/nst0 Product Type: Tape Drive Vendor ID: 'IBM ' Product ID: 'ULT3580-HH7 ' Revision: 'G9Q1' Attached Changer API: No SerialNumber: '1097000515' MinBlock: 1 MaxBlock: 8388608 SCSI ID: 1 SCSI LUN: 0 Ready: yes BufferedMode: yes Medium Type: 0x78 Density Code: 0x5c BlockSize: 0 DataCompEnabled: yes DataCompCapable: yes DataDeCompEnabled: yes CompType: 0xff DeCompType: 0xff BOP: yes Block Position: 0 Partition 0 Remaining Kbytes: -1 Partition 0 Size in Kbytes: -1 ActivePartition: 0 EarlyWarningSize: 0 NumPartitions: 0 MaxPartitions: 3 # lsscsi -g [3:0:1:0] tape IBM ULT3580-HH7 G9Q1 /dev/st0 /dev/sg5 [3:0:1:1] mediumx IBM 3572-TL 0071 - /dev/sg6 Device { Name = Drive-1 # Drive Index = 0 Media Type = LTO-7 Archive Device = /dev/nst0 AutomaticMount = yes; # when device opened, read it AlwaysOpen = yes; RemovableMedia = yes; RandomAccess = no; AutoChanger = yes Alert Command = "sh -c 'tapeinfo -f %c |grep TapeAlert|cat'" } Jim Richardson Note: In HP Library and Tape Tools, Aaron could not find a similar setting for his LTO6 drive. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2017-07-25 01:04 agreenblatt New Issue ====================================================================== |
From: Mantis B. T. <no...@bu...> - 2017-07-24 04:53:35
|
The following issue has been CLOSED ====================================================================== http://bugs.bacula.org/view.php?id=2297 ====================================================================== Reported By: ty0101 Assigned To: ====================================================================== Project: Bacula Bug Reports Issue ID: 2297 Category: configure/build process Reproducibility: have not tried Severity: minor Priority: normal Status: closed Resolution: fixed Fixed in Version: ====================================================================== Date Submitted: 2017-07-24 04:01 BST Last Modified: 2017-07-24 05:53 BST ====================================================================== Summary: 'make' tasks in Bacula 9.0.1 fails with error: ‘struct bctx_t’ has no member named ‘max_compress_len’ Description: Similar to issue ID: 2163, the `make` command results in the following output: root@bacula filed]# make <successful output omitted by me> ==>Entering directory /usr/src/bacula-9.0.1/src/filed make[1]: Entering directory `/usr/src/bacula-9.0.1/src/filed' Compiling filed.c Compiling authenticate.c Compiling backup.c backup.c: In function ‘bool setup_compression(bctx_t&)’: backup.c:1080:9: error: ‘struct bctx_t’ has no member named ‘max_compress_len’ bctx.max_compress_len = 0; ^ backup.c:1022:9: warning: unused variable ‘jcr’ [-Wunused-variable] JCR *jcr = bctx.jcr; ^ make[1]: *** [backup.o] Error 1 make[1]: Leaving directory `/usr/src/bacula-9.0.1/src/filed' ====== Error in /usr/src/bacula-9.0.1/src/filed ====== make: *** [all] Error 1 Steps to Reproduce: Here is the list of all the commands I took up to this point: yum install readline-devel yum install -y wget yum install -y vim yum install postgresql96-server.x86_64 yum install -y postgresql96-devel /usr/pgsql-9.6/bin/postgresql96-setup initdb systemctl enable postgresql-9.6.service firewall-cmd --permanent --zone=public –add-port=9101-9103/tcp firewall-cmd --reload #Make bacula easier to recognize with network administrator (netstat -a) vim /etc/services mkdir /bacula #Install Bacula binarires wget -O- https://sourceforge.net/projects/bacula/files/bacula/9.0.1/bacula-9.0.1.tar.gz/download | tar -xzvf - -C /usr/src #Configure file system mkdir /opt/bacula mkdir /opt/bacula/bin mkdir /opt/bacula/etc mkdir /opt/bacula/work cd /usr/src/bacula-9.0.1 #install dependency needed for CFLAGS yum install gcc yum install gcc-c++ yum install libacl-devel #configure stuff, using appropriate flags cd /usr/src/bacula-9.0.1 ./script-configure.sh (shown below) #script-config.sh contents: -------------------------------------------------------- #!/bin/bash CFLAGS="-g -Wall" \ ./configure \ --enable-smartalloc \ --sbindir=/opt/bacula/bin \ --sysconfdir=/opt/bacula/etc \ --with-pid-dir=/opt/bacula/work \ --with-subsys-dir=/opt/bacula/work \ --with-postgresql=/usr/pgsql-9.6 \ --with-python=/usr/bin/python \ --with-working-dir=/opt/bacula/work \ --with-dump-email=$USER ------------------------------------------------------------- make Additional Information: Using Bacula 9.0.1 ====================================================================== ---------------------------------------------------------------------- (0007591) kern (administrator) - 2017-07-24 05:53 http://bugs.bacula.org/view.php?id=2297#c7591 ---------------------------------------------------------------------- Yes, this is a bug. However, it is easily corrected by you. You are undoubtedly missing either libz or lzo or both. Actually the symbol is defined by the libz (I think it is libz-devel on RedHat). I recommend having both. You will need both the runtime libraries (on the FD machine) and the devel libraries to be able to build Bacula. However, this problem has been fixed in the latest version 9.0.2, which I will be releasing today. Version 9.0.2 is already in the git repository. I am closing this bug because it is already resolved (as of yesterday). Issue History Date Modified Username Field Change ====================================================================== 2017-07-24 04:01 ty0101 New Issue 2017-07-24 05:53 kern Status new => closed 2017-07-24 05:53 kern Resolution open => fixed 2017-07-24 05:53 kern Note Added: 0007591 ====================================================================== |
From: Mantis B. T. <no...@bu...> - 2017-07-24 03:03:06
|
Issue 0002297 is now monitored by user ty0101. ====================================================================== http://bugs.bacula.org/view.php?id=2297 ====================================================================== Reported By: ty0101 Assigned To: ====================================================================== Project: Bacula Bug Reports Issue ID: 2297 Category: configure/build process Reproducibility: have not tried Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2017-07-24 04:01 BST Last Modified: 2017-07-24 04:02 BST ====================================================================== Summary: 'make' tasks in Bacula 9.0.1 fails with error: ‘struct bctx_t’ has no member named ‘max_compress_len’ Description: Similar to issue ID: 2163, the `make` command results in the following output: root@bacula filed]# make <successful output omitted by me> ==>Entering directory /usr/src/bacula-9.0.1/src/filed make[1]: Entering directory `/usr/src/bacula-9.0.1/src/filed' Compiling filed.c Compiling authenticate.c Compiling backup.c backup.c: In function ‘bool setup_compression(bctx_t&)’: backup.c:1080:9: error: ‘struct bctx_t’ has no member named ‘max_compress_len’ bctx.max_compress_len = 0; ^ backup.c:1022:9: warning: unused variable ‘jcr’ [-Wunused-variable] JCR *jcr = bctx.jcr; ^ make[1]: *** [backup.o] Error 1 make[1]: Leaving directory `/usr/src/bacula-9.0.1/src/filed' ====== Error in /usr/src/bacula-9.0.1/src/filed ====== make: *** [all] Error 1 Steps to Reproduce: Here is the list of all the commands I took up to this point: yum install readline-devel yum install -y wget yum install -y vim yum install postgresql96-server.x86_64 yum install -y postgresql96-devel /usr/pgsql-9.6/bin/postgresql96-setup initdb systemctl enable postgresql-9.6.service firewall-cmd --permanent --zone=public –add-port=9101-9103/tcp firewall-cmd --reload #Make bacula easier to recognize with network administrator (netstat -a) vim /etc/services mkdir /bacula #Install Bacula binarires wget -O- https://sourceforge.net/projects/bacula/files/bacula/9.0.1/bacula-9.0.1.tar.gz/download | tar -xzvf - -C /usr/src #Configure file system mkdir /opt/bacula mkdir /opt/bacula/bin mkdir /opt/bacula/etc mkdir /opt/bacula/work cd /usr/src/bacula-9.0.1 #install dependency needed for CFLAGS yum install gcc yum install gcc-c++ yum install libacl-devel #configure stuff, using appropriate flags cd /usr/src/bacula-9.0.1 ./script-configure.sh (shown below) #script-config.sh contents: -------------------------------------------------------- #!/bin/bash CFLAGS="-g -Wall" \ ./configure \ --enable-smartalloc \ --sbindir=/opt/bacula/bin \ --sysconfdir=/opt/bacula/etc \ --with-pid-dir=/opt/bacula/work \ --with-subsys-dir=/opt/bacula/work \ --with-postgresql=/usr/pgsql-9.6 \ --with-python=/usr/bin/python \ --with-working-dir=/opt/bacula/work \ --with-dump-email=$USER ------------------------------------------------------------- make Additional Information: Using Bacula 9.0.1 ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2017-07-24 04:01 ty0101 New Issue ====================================================================== |
From: Mantis B. T. <no...@bu...> - 2017-07-24 03:02:06
|
The following issue has been SUBMITTED. ====================================================================== http://bugs.bacula.org/view.php?id=2297 ====================================================================== Reported By: ty0101 Assigned To: ====================================================================== Project: Bacula Bug Reports Issue ID: 2297 Category: configure/build process Reproducibility: have not tried Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2017-07-24 04:01 BST Last Modified: 2017-07-24 04:01 BST ====================================================================== Summary: 'make' tasks in Bacula 9.0.1 fails with error: ‘struct bctx_t’ has no member named ‘max_compress_len’ Description: Similar to issue ID: 2163, the `make` command results in the following output: root@bacula filed]# make <successful output omitted by me> ==>Entering directory /usr/src/bacula-9.0.1/src/filed make[1]: Entering directory `/usr/src/bacula-9.0.1/src/filed' Compiling filed.c Compiling authenticate.c Compiling backup.c backup.c: In function ‘bool setup_compression(bctx_t&)’: backup.c:1080:9: error: ‘struct bctx_t’ has no member named ‘max_compress_len’ bctx.max_compress_len = 0; ^ backup.c:1022:9: warning: unused variable ‘jcr’ [-Wunused-variable] JCR *jcr = bctx.jcr; ^ make[1]: *** [backup.o] Error 1 make[1]: Leaving directory `/usr/src/bacula-9.0.1/src/filed' ====== Error in /usr/src/bacula-9.0.1/src/filed ====== make: *** [all] Error 1 Steps to Reproduce: Here is the list of all the commands I took up to this point: yum install readline-devel yum install -y wget yum install -y vim yum install postgresql96-server.x86_64 yum install -y postgresql96-devel /usr/pgsql-9.6/bin/postgresql96-setup initdb systemctl enable postgresql-9.6.service firewall-cmd --permanent --zone=public –add-port=9101-9103/tcp firewall-cmd --reload #Make bacula easier to recognize with network administrator (netstat -a) vim /etc/services mkdir /bacula #Install Bacula binarires wget -O- https://sourceforge.net/projects/bacula/files/bacula/9.0.1/bacula-9.0.1.tar.gz/download | tar -xzvf - -C /usr/src #Configure file system mkdir /opt/bacula mkdir /opt/bacula/bin mkdir /opt/bacula/etc mkdir /opt/bacula/work cd /usr/src/bacula-9.0.1 #install dependency needed for CFLAGS yum install gcc yum install gcc-c++ yum install libacl-devel #configure stuff, using appropriate flags cd /usr/src/bacula-9.0.1 ./script-configure.sh (shown below) #script-config.sh contents: -------------------------------------------------------- #!/bin/bash CFLAGS="-g -Wall" \ ./configure \ --enable-smartalloc \ --sbindir=/opt/bacula/bin \ --sysconfdir=/opt/bacula/etc \ --with-pid-dir=/opt/bacula/work \ --with-subsys-dir=/opt/bacula/work \ --with-postgresql=/usr/pgsql-9.6 \ --with-python=/usr/bin/python \ --with-working-dir=/opt/bacula/work \ --with-dump-email=$USER ------------------------------------------------------------- make Additional Information: Using Bacula 9.0.1 ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2017-07-24 04:01 ty0101 New Issue ====================================================================== |
From: Mantis B. T. <no...@bu...> - 2017-07-23 08:45:18
|
The following issue requires your FEEDBACK. ====================================================================== http://bugs.bacula.org/view.php?id=2249 ====================================================================== Reported By: wandihuttel Assigned To: kern ====================================================================== Project: Bacula Bug Reports Issue ID: 2249 Category: bconsole Reproducibility: always Severity: minor Priority: normal Status: feedback ====================================================================== Date Submitted: 2016-10-03 14:34 BST Last Modified: 2017-07-23 09:45 BST ====================================================================== Summary: [PATCH] Include elapsed time in restore and verify jobs in JobLog Description: I'm submiting a patch to include Elapsed Time in "restore" and "verify" jobs. In restore Jobs I've modified "Bytes Restored" to show bytes in human_readable format, using the function (edit_uint64_with_suffix) like backup.c ====================================================================== ---------------------------------------------------------------------- (0007577) wandihuttel (reporter) - 2017-07-13 17:38 http://bugs.bacula.org/view.php?id=2249#c7577 ---------------------------------------------------------------------- Hello I'm attaching the patches for the 9.0.1 version. ---------------------------------------------------------------------- (0007590) kern (administrator) - 2017-07-23 09:45 http://bugs.bacula.org/view.php?id=2249#c7590 ---------------------------------------------------------------------- These patches do not apply. Please use the repo and git to produce them. Issue History Date Modified Username Field Change ====================================================================== 2016-10-03 14:34 wandihuttel New Issue 2016-10-03 14:34 wandihuttel File Added: restore.c.patch 2016-10-03 14:36 wandihuttel File Added: verify.c.patch 2016-10-14 17:06 kern Assigned To => kern 2016-10-14 17:06 kern Status new => acknowledged 2016-10-14 17:06 kern Summary Include elapsed time in restore and verify jobs in JobLog => [PATCH] Include elapsed time in restore and verify jobs in JobLog 2017-07-13 17:38 wandihuttel File Added: restore-9.0.1.c.patch 2017-07-13 17:38 wandihuttel File Added: verify-9.0.1.c.patch 2017-07-13 17:38 wandihuttel Note Added: 0007577 2017-07-23 09:45 kern Status acknowledged => feedback 2017-07-23 09:45 kern Note Added: 0007590 ====================================================================== |
From: Mantis B. T. <no...@bu...> - 2017-07-23 08:31:48
|
The following issue has been CLOSED ====================================================================== http://bugs.bacula.org/view.php?id=2255 ====================================================================== Reported By: wandihuttel Assigned To: kern ====================================================================== Project: Bacula Bug Reports Issue ID: 2255 Category: bconsole Reproducibility: always Severity: minor Priority: normal Status: closed Resolution: fixed Fixed in Version: ====================================================================== Date Submitted: 2016-11-01 00:32 GMT Last Modified: 2017-07-23 09:31 BST ====================================================================== Summary: Increase volume label size and decrease media type output and beautify command "status slots" Description: When the volume label are bigger than 16 characters, the command "update slots" doesn't show correctly the table. I suggest increase "Volume Name" to 30 characters in this output and decrease to 10 characters the "Media Type" Currently in version 7.4.4 ################################################################################################ *status slots drive=0 Automatically selected Storage: VirtualChanger Automatically selected Catalog: MyCatalog Using Catalog "MyCatalog" Connecting to Storage daemon VirtualChanger at 192.168.1.3:9103 ... 3306 Issuing autochanger "slots" command. Device "VirtualChanger" has 30 slots. Connecting to Storage daemon VirtualChanger at 192.168.1.3:9103 ... 3306 Issuing autochanger "list" command. Slot | Volume Name | Status | Media Type | Pool | ------+------------------+-----------+----------------------+--------------------| 1 | Volume-Diario-0001 | Append | File | Diaria | 2 | Volume-Diario-0002 | Append | File | Diaria | 3 | Volume-Diario-0003 | Append | File | Diaria | 4 | Volume-Diario-0004 | Append | File | Diaria | 5 | Volume-Diario-0005 | Append | File | Diaria | 6 | Volume-Diario-0006 | Append | File | Diaria | 7 | Volume-Diario-0007 | Append | File | Diaria | 8 | Volume-Diario-0008 | Append | File | Diaria | 9 | Volume-Diario-0009 | Append | File | Diaria | 10 | Volume-Diario-0010 | Append | File | Diaria | 11 | Volume-Mensal-0001 | Append | File | Mensal | 12 | Volume-Mensal-0002 | Append | File | Mensal | 13 | Volume-Mensal-0003 | Append | File | Mensal | 14 | Volume-Mensal-0004 | Append | File | Mensal | 15 | Volume-Mensal-0005 | Append | File | Mensal | 16 | Volume-Mensal-0006 | Append | File | Mensal | 17 | Volume-Mensal-0007 | Append | File | Mensal | 18 | Volume-Mensal-0008 | Append | File | Mensal | 19 | Volume-Mensal-0009 | Append | File | Mensal | 20 | Volume-Mensal-0010 | Append | File | Mensal | 21 | Volume-Semanal-0001 | Append | File | Semanal | 22 | Volume-Semanal-0002 | Append | File | Semanal | 23 | Volume-Semanal-0003 | Append | File | Semanal | 24 | Volume-Semanal-0004 | Append | File | Semanal | 25 | Volume-Semanal-0005 | Append | File | Semanal | 26 | Volume-Semanal-0006 | Append | File | Semanal | 27 | Volume-Semanal-0007 | Append | File | Semanal | 28 | Volume-Semanal-0008 | Append | File | Semanal | 29 | Volume-Semanal-0009 | Append | File | Semanal | 30 | Volume-Semanal-0010 | Append | File | Semanal | ################################################################################################ After changes: *status slots drive=0 Automatically selected Storage: VirtualChanger Connecting to Storage daemon VirtualChanger at 192.168.1.3:9103 ... 3306 Issuing autochanger "slots" command. Device "VirtualChanger" has 30 slots. Connecting to Storage daemon VirtualChanger at 192.168.1.3:9103 ... 3306 Issuing autochanger "list" command. +------+--------------------------------+-----------+------------+--------------------+ | Slot | Volume Name | Status | Media Type | Pool | +------+--------------------------------+-----------+------------+--------------------+ | 1 | Volume-Diario-0001 | Append | File | Diaria | | 2 | Volume-Diario-0002 | Append | File | Diaria | | 3 | Volume-Diario-0003 | Append | File | Diaria | | 4 | Volume-Diario-0004 | Append | File | Diaria | | 5 | Volume-Diario-0005 | Append | File | Diaria | | 6 | Volume-Diario-0006 | Append | File | Diaria | | 7 | Volume-Diario-0007 | Append | File | Diaria | | 8 | Volume-Diario-0008 | Append | File | Diaria | | 9 | Volume-Diario-0009 | Append | File | Diaria | | 10 | Volume-Diario-0010 | Append | File | Diaria | | 11 | Volume-Mensal-0001 | Append | File | Mensal | | 12 | Volume-Mensal-0002 | Append | File | Mensal | | 13 | Volume-Mensal-0003 | Append | File | Mensal | | 14 | Volume-Mensal-0004 | Append | File | Mensal | | 15 | Volume-Mensal-0005 | Append | File | Mensal | | 16 | Volume-Mensal-0006 | Append | File | Mensal | | 17 | Volume-Mensal-0007 | Append | File | Mensal | | 18 | Volume-Mensal-0008 | Append | File | Mensal | | 19 | Volume-Mensal-0009 | Append | File | Mensal | | 20 | Volume-Mensal-0010 | Append | File | Mensal | | 21 | Volume-Semanal-0001 | Append | File | Semanal | | 22 | Volume-Semanal-0002 | Append | File | Semanal | | 23 | Volume-Semanal-0003 | Append | File | Semanal | | 24 | Volume-Semanal-0004 | Append | File | Semanal | | 25 | Volume-Semanal-0005 | Append | File | Semanal | | 26 | Volume-Semanal-0006 | Append | File | Semanal | | 27 | Volume-Semanal-0007 | Append | File | Semanal | | 28 | Volume-Semanal-0008 | Append | File | Semanal | | 29 | Volume-Semanal-0009 | Append | File | Semanal | | 30 | Volume-Semanal-0010 | Append | File | Semanal | +------+--------------------------------+-----------+------------+--------------------+ ====================================================================== ---------------------------------------------------------------------- (0007589) kern (administrator) - 2017-07-23 09:31 http://bugs.bacula.org/view.php?id=2255#c7589 ---------------------------------------------------------------------- The patch would not apply either with git nor with patch, so I applied it manually, but used some slightly different sizes. Thanks for the patch. Issue History Date Modified Username Field Change ====================================================================== 2016-11-01 00:32 wandihuttel New Issue 2016-11-01 00:32 wandihuttel File Added: ua_label.c.patch 2016-11-01 09:43 wandihuttel File Added: status_slots.png 2017-07-09 12:06 kern Assigned To => kern 2017-07-09 12:06 kern Status new => acknowledged 2017-07-23 09:31 kern Status acknowledged => closed 2017-07-23 09:31 kern Resolution open => fixed 2017-07-23 09:31 kern Note Added: 0007589 ====================================================================== |
From: Mantis B. T. <no...@bu...> - 2017-07-23 07:37:37
|
The following issue requires your FEEDBACK. ====================================================================== http://bugs.bacula.org/view.php?id=2267 ====================================================================== Reported By: djosip Assigned To: kern ====================================================================== Project: Bacula Bug Reports Issue ID: 2267 Category: other Tags: volume copy job flag level Reproducibility: always Severity: major Priority: normal Status: feedback ====================================================================== Date Submitted: 2017-02-27 11:18 GMT Last Modified: 2017-07-23 08:37 BST ====================================================================== Summary: Discrepancy between the original and the copy jobs regarding the backup level flag Description: My version of Bacula is actually 7.0.5 but I had to to chose 7.2.0 when reporting the bug because this is the closest version I was offered from the pull-down menu. I have found that when a job gets copied to a volume at the secondary location, its level flag in the volume changes from full to incremental while the entry in the database looks exactly as it should. I have used the bls tool to list the jobs in the volume at the secondary location (I am using disk backup if that matters). I have first brought this to the Bacula user list where Mr. Martin Simmons confirmed my findings. He observed the same thing (with differential jobs in his case) and he also pointed out that the level flag the copied jobs gets written to the volume corresponds to the level initially set in the job resource definition. After some additional tests I was able to confirm this. This discrepancy between original and the copied jobs adds to the sum of inconsistencies and I believe it is a bug that needs to be fixed. It is not a burning matter but it could prevent people from doing disaster recovery without a catalog. Steps to Reproduce: 1. Define a backup job resource as usual and make sure you define job level as incremental or differential. 2. Run the job from the previous step using the full level. 3. Define a copy job and configure it so that it targets the job from the previous step and perform a copy of the job to a separate pool of volumes. 4. Using bls tool check the job from the original volume and compare it with the bls output from the volume that contains the copied job. The first one will have a flag "F" (which is ok) while the second will not (it will have a flag that corresponds to the backup level defined in the job resource definition in the step 1.). ====================================================================== ---------------------------------------------------------------------- (0007588) kern (administrator) - 2017-07-23 08:37 http://bugs.bacula.org/view.php?id=2267#c7588 ---------------------------------------------------------------------- Bacula version 9.0.2 has a patch that *should* fix this problem. Please test it. It is currently in the git repo and will be released in a couple of days. If this still happens, I will create a test case as you suggest to see if we can fix it. Issue History Date Modified Username Field Change ====================================================================== 2017-02-27 11:18 djosip New Issue 2017-02-27 11:18 djosip Tag Attached: volume copy job flag level 2017-07-09 12:03 kern Assigned To => kern 2017-07-09 12:03 kern Status new => acknowledged 2017-07-23 08:37 kern Status acknowledged => feedback 2017-07-23 08:37 kern Note Added: 0007588 ====================================================================== |
From: Mantis B. T. <no...@bu...> - 2017-07-23 07:15:54
|
The following issue has been CLOSED ====================================================================== http://bugs.bacula.org/view.php?id=2292 ====================================================================== Reported By: slaanesh Assigned To: kern ====================================================================== Project: Bacula Bug Reports Issue ID: 2292 Category: tray-monitor Reproducibility: always Severity: block Priority: high Status: closed Resolution: fixed Fixed in Version: ====================================================================== Date Submitted: 2017-07-10 09:25 BST Last Modified: 2017-07-23 08:15 BST ====================================================================== Summary: Unable to build tray-monitor. Files missing in the source? Description: Whenver I try to build the new tray monitor, I get this message: + pushd src/qt-console/tray-monitor + /usr/lib64/qt4/bin/qmake 'QMAKE_CFLAGS_DEBUG=-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -I/usr/include/ncurses' 'QMAKE_CFLAGS_RELEASE=-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -I/usr/include/ncurses' 'QMAKE_CXXFLAGS_DEBUG=-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic' 'QMAKE_CXXFLAGS_RELEASE=-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic' 'QMAKE_LFLAGS_DEBUG=-Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld' 'QMAKE_LFLAGS_RELEASE=-Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld' QMAKE_STRIP= tray-monitor.pro WARNING: Failure to find: task.cpp WARNING: Failure to find: sdstatus.cpp WARNING: Failure to find: runjob.cpp WARNING: Failure to find: status.cpp WARNING: Failure to find: conf.h WARNING: Failure to find: sdstatus.h WARNING: Failure to find: runjob.h WARNING: Failure to find: status.h WARNING: Failure to find: sd-monitor.ui WARNING: Failure to find: main-conf.ui WARNING: Failure to find: res-conf.ui WARNING: Failure to find: run.ui + make -j8 /usr/lib64/qt4/bin/uic fd-monitor.ui -o ui/ui_fd-monitor.h /usr/lib64/qt4/bin/uic dir-monitor.ui -o ui/ui_dir-monitor.h make: *** No rule to make target 'sd-monitor.ui', needed by 'ui/ui_sd-monitor.h'. Stop. make: *** Waiting for unfinished jobs.... It seems some UI files are missing from the source repository. Steps to Reproduce: Try to build the tray monitor. Additional Information: Can't push the updated packages for RHEL/Fedora until tray monitor is built. ====================================================================== ---------------------------------------------------------------------- (0007557) slaanesh (reporter) - 2017-07-10 09:26 http://bugs.bacula.org/view.php?id=2292#c7557 ---------------------------------------------------------------------- Marked as "blocker" as it's a regression and I can't build updated packages without sacrificing functionality. Thanks. ---------------------------------------------------------------------- (0007559) kern (administrator) - 2017-07-10 10:10 http://bugs.bacula.org/view.php?id=2292#c7559 ---------------------------------------------------------------------- Ugly! One of the things I could not get to myself it building the tray-monitor. I will look into this right away. ---------------------------------------------------------------------- (0007560) kern (administrator) - 2017-07-10 10:19 http://bugs.bacula.org/view.php?id=2292#c7560 ---------------------------------------------------------------------- It looks like I totally forgot to include all the new files from the Enterprise version for tray-monitor. My schedule is a bit heavy for the next couple of days, so I suggest that you temporarily leave the tray-monitor out of your build. I am a bit surprised that in building our binaries (done by someone else) this was not pointed out! Once I copy over all the files and adjust the copyrights accordingly then build and test it myself, I will release a new version. I will also post a note to this bug report. Thanks for reporting this, and sorry for the inconvenience. ---------------------------------------------------------------------- (0007561) slaanesh (reporter) - 2017-07-10 11:33 http://bugs.bacula.org/view.php?id=2292#c7561 ---------------------------------------------------------------------- Thanks. Build has been disabled for now. Probably this could have also been catched before the release, but unfortunately I'm also swamped with my job and had no time to build any of the pre-releases you announced. Sorry for that. ---------------------------------------------------------------------- (0007566) kern (administrator) - 2017-07-10 19:21 http://bugs.bacula.org/view.php?id=2292#c7566 ---------------------------------------------------------------------- I would appreciate it if you could pull the latest git repository code and test. The tray-monitor should now build correctly, and though I didn't completely test it, the resulting binary was able to display the its configuration dialog. ---------------------------------------------------------------------- (0007567) slaanesh (reporter) - 2017-07-11 08:19 http://bugs.bacula.org/view.php?id=2292#c7567 ---------------------------------------------------------------------- Commit http://bacula.org/git/cgit.cgi/bacula/commit/?id=a34f61be3e65120b8b22d306c0718d7a5aec7bc1 fixes the tray monitor build, I'll test it shortly. ---------------------------------------------------------------------- (0007569) slaanesh (reporter) - 2017-07-11 08:31 http://bugs.bacula.org/view.php?id=2292#c7569 ---------------------------------------------------------------------- Btw, the "generic.xpm" icon that used to be in the old tray-monitor source is no longer available: http://bacula.org/git/cgit.cgi/bacula/tree/bacula/scripts/bacula-tray-monitor.desktop.in#n4 Is there any place where we can get a recent tray monitor icon? ---------------------------------------------------------------------- (0007570) slaanesh (reporter) - 2017-07-11 08:39 http://bugs.bacula.org/view.php?id=2292#c7570 ---------------------------------------------------------------------- Also, here: http://bacula.org/git/cgit.cgi/bacula/tree/bacula/configure#n31195 We should probably add "scripts/bacula-tray-monitor.desktop.in" to the list of files, as it's missing. ---------------------------------------------------------------------- (0007587) kern (administrator) - 2017-07-23 08:15 http://bugs.bacula.org/view.php?id=2292#c7587 ---------------------------------------------------------------------- This issue is now resolved. I have pushed the fix to the git repo, and I will release version 9.0.2 in the next few days. I have also added the tray-monitor-desktop as suggested. Issue History Date Modified Username Field Change ====================================================================== 2017-07-10 09:25 slaanesh New Issue 2017-07-10 09:26 slaanesh Note Added: 0007557 2017-07-10 10:10 kern Assigned To => kern 2017-07-10 10:10 kern Status new => confirmed 2017-07-10 10:10 kern Note Added: 0007559 2017-07-10 10:19 kern Note Added: 0007560 2017-07-10 11:33 slaanesh Note Added: 0007561 2017-07-10 19:21 kern Status confirmed => feedback 2017-07-10 19:21 kern Note Added: 0007566 2017-07-11 08:19 slaanesh Note Added: 0007567 2017-07-11 08:19 slaanesh Status feedback => assigned 2017-07-11 08:31 slaanesh Note Added: 0007569 2017-07-11 08:39 slaanesh Note Added: 0007570 2017-07-11 08:44 slaanesh File Added: bacula-9.0.0-tray-monitor-desktop.patch 2017-07-23 08:15 kern Status assigned => closed 2017-07-23 08:15 kern Resolution open => fixed 2017-07-23 08:15 kern Note Added: 0007587 ====================================================================== |
From: Mantis B. T. <no...@bu...> - 2017-07-21 13:24:46
|
The following issue has been CLOSED ====================================================================== http://bugs.bacula.org/view.php?id=2296 ====================================================================== Reported By: harvey637 Assigned To: kern ====================================================================== Project: Bacula Bug Reports Issue ID: 2296 Category: configure/build process Tags: Postgresql Reproducibility: always Severity: block Priority: high Status: closed Resolution: fixed Fixed in Version: ====================================================================== Date Submitted: 2017-07-18 10:28 BST Last Modified: 2017-07-21 14:24 BST ====================================================================== Summary: cannot build bacula 9.0.1 with postgresql 8 due to PQconnectdbParams in src/cats/postgresql.c line 281 Description: The way bacula connects to postgres requires postgres version >= 9. Only in this version the used " mdb->m_db_handle = PQconnectdbParams(keywords, values, 0);" is declared in libpq-fe.h. extract from libpg-fe.h from postgres 9.6: /* === in fe-connect.c === */ /* make a new client connection to the backend */ /* Asynchronous (non-blocking) */ extern PGconn *PQconnectStart(const char *conninfo); extern PGconn *PQconnectStartParams(const char *const * keywords, const char *const * values, int expand_dbname); extern PostgresPollingStatusType PQconnectPoll(PGconn *conn); /* Synchronous (blocking) */ extern PGconn *PQconnectdb(const char *conninfo); extern PGconn *PQconnectdbParams(const char *const * keywords, const char *const * values, int expand_dbname); extern PGconn *PQsetdbLogin(const char *pghost, const char *pgport, const char *pgoptions, const char *pgtty, const char *dbName, const char *login, const char *pwd); #define PQsetdb(M_PGHOST,M_PGPORT,M_PGOPT,M_PGTTY,M_DBNAME) \ PQsetdbLogin(M_PGHOST, M_PGPORT, M_PGOPT, M_PGTTY, M_DBNAME, NULL, NULL) /* close the current connection and free the PGconn data structure */ extern void PQfinish(PGconn *conn); extract from libpq-fe.h from postgresql 8.4 /* === in fe-connect.c === */ /* make a new client connection to the backend */ /* Asynchronous (non-blocking) */ extern PGconn *PQconnectStart(const char *conninfo); extern PostgresPollingStatusType PQconnectPoll(PGconn *conn); /* Synchronous (blocking) */ extern PGconn *PQconnectdb(const char *conninfo); extern PGconn *PQsetdbLogin(const char *pghost, const char *pgport, const char *pgoptions, const char *pgtty, const char *dbName, const char *login, const char *pwd); #define PQsetdb(M_PGHOST,M_PGPORT,M_PGOPT,M_PGTTY,M_DBNAME) \ PQsetdbLogin(M_PGHOST, M_PGPORT, M_PGOPT, M_PGTTY, M_DBNAME, NULL, NULL) /* close the current connection and free the PGconn data structure */ extern void PQfinish(PGconn *conn); /* get info about connection options known to PQconnectdb */ extern PQconninfoOption *PQconndefaults(void); /* parse connection options in same way as PQconnectdb */ extern PQconninfoOption *PQconninfoParse(const char *conninfo, char **errmsg); /* free the data structure returned by PQconndefaults() or PQconninfoParse() */ extern void PQconninfoFree(PQconninfoOption *connOptions); The use of the different connections are also seen inside postgresql.c Line 248 in bacula version 7.4.7: /* connect to the database */ mdb->m_db_handle = PQsetdbLogin( mdb->m_db_address, /* default = localhost */ port, /* default port */ NULL, /* pg options */ NULL, /* tty, ignored */ mdb->m_db_name, /* database name */ mdb->m_db_user, /* login name */ mdb->m_db_password); /* password */ /* If no connect, try once more in case it is a timing problem */ if (PQstatus(mdb->m_db_handle) == CONNECTION_OK) { break; } and in line 261 in bacula version 9.0.1 file postgresql.c: /* connect to the database */ const char *keywords[10] = {"host", "port", "dbname", "user", "password", "sslmode", "sslkey", "sslcert", "sslrootcert", NULL }; const char *values[10] = {mdb->m_db_address, /* default localhost */ port, /* default port */ mdb->m_db_name, mdb->m_db_user, mdb->m_db_password, mdb->m_db_ssl_mode, mdb->m_db_ssl_key, mdb->m_db_ssl_cert, mdb->m_db_ssl_ca, NULL }; mdb->m_db_handle = PQconnectdbParams(keywords, values, 0); /* If no connect, try once more in case it is a timing problem */ if (PQstatus(mdb->m_db_handle) == CONNECTION_OK) { break; } Steps to Reproduce: autoconfig and rpmbuild. problem is clearly seen in postgresql.c and libpq-fe.h not dependend on anything but the version of the postgres database and version of the postgres develoment files in version 8.4 and in version 9.6. Additional Information: server (on which the compile does not work with bacula 9.0.1) is the server with a running bacula version 7.4.7 (director) and postgres database version 8.4 with all development tools and libraries that belong to standard centos version 6.8. As a very last option it might be possible to switch to centos7 and postgresql 9.6, but this disrupts backup continuity. If postgres 8.4 is abandoned with bacula 9.0.1 it should be stated clearly in the docs and in the requirements. (by the way, mantis should support versions > 7.4.7 as bacula version :-) output of build process: Compiling sql_update.c Compiling cats_null.c Compiling postgresql.c Making libbacsql.la ... /root/rpmbuild/BUILD/bacula-9.0.1/libtool --silent --tag=CXX --mode=link /usr/bin/g++ -o libbacsql.la bvfs.lo cats.lo sql.lo sql_cmds.lo sql_create.lo sql_delete.lo sql_find.lo sql_get.lo sql_list.lo sql_update.lo -export-dynamic -rpath /opt/bacula/lib64 -release 9.0.1 Making libbaccats.la ... /root/rpmbuild/BUILD/bacula-9.0.1/libtool --silent --tag=CXX --mode=link /usr/bin/g++ -o libbaccats.la cats_null.lo -export-dynamic -rpath /opt/bacula/lib64 -release 9.0.1 postgresql.c: In member function 'virtual bool BDB_POSTGRESQL::bdb_open_database(JCR*)': postgresql.c:281: error: 'PQconnectdbParams' was not declared in this scope make[1]: *** [postgresql.lo] Error 1 make[1]: *** Waiting for unfinished jobs.... make[1]: Leaving directory `/root/rpmbuild/BUILD/bacula-9.0.1/src/cats' ====== Error in /root/rpmbuild/BUILD/bacula-9.0.1/src/cats ====== ====================================================================== ---------------------------------------------------------------------- (0007586) kern (administrator) - 2017-07-21 14:24 http://bugs.bacula.org/view.php?id=2296#c7586 ---------------------------------------------------------------------- This build problem *should* now be fixed in the version that I just pushed to the git repo. Issue History Date Modified Username Field Change ====================================================================== 2017-07-18 10:28 harvey637 New Issue 2017-07-18 10:28 harvey637 Tag Attached: Postgresql 2017-07-18 10:52 kern Assigned To => kern 2017-07-18 10:52 kern Status new => acknowledged 2017-07-21 14:24 kern Status acknowledged => closed 2017-07-21 14:24 kern Resolution open => fixed 2017-07-21 14:24 kern Note Added: 0007586 ====================================================================== |
From: Mantis B. T. <no...@bu...> - 2017-07-20 17:45:53
|
The following issue has been CLOSED ====================================================================== http://bugs.bacula.org/view.php?id=2294 ====================================================================== Reported By: slaanesh Assigned To: ====================================================================== Project: Bacula Bug Reports Issue ID: 2294 Category: sql Reproducibility: always Severity: major Priority: normal Status: closed Resolution: fixed Fixed in Version: ====================================================================== Date Submitted: 2017-07-11 09:01 BST Last Modified: 2017-07-20 18:45 BST ====================================================================== Summary: Unable to build with Maria DB 10.2 Description: MariaDB 10.2 introduce some changes, including a rename from "libmysqlclient.so" to "libmariadb.so". This is the result when compiling the recent Bacula 9.0.0 release with Maria DB 10.2: Making libbacsql.la ... /builddir/build/BUILD/bacula-9.0.0/libtool --silent --tag=CXX --mode=link /usr/bin/g++ -Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -o libbacsql.la bvfs.lo cats.lo sql.lo sql_cmds.lo sql_create.lo sql_delete.lo sql_find.lo sql_get.lo sql_list.lo sql_update.lo -export-dynamic -rpath /usr/lib64 -release 9.0.0 mysql.c: In member function 'virtual bool BDB_MYSQL::bdb_open_database(JCR*)': mysql.c:261:20: error: 'MYSQL {aka struct st_mysql}' has no member named 'reconnect' mdb->m_instance.reconnect = 1; /* so connection does not timeout */ ^~~~~~~~~ make[1]: *** [Makefile:183: mysql.lo] Error 1 make[1]: *** Waiting for unfinished jobs.... Steps to Reproduce: Compile against MariaDB 10.2. Additional Information: Originally reported here: https://bugzilla.redhat.com/show_bug.cgi?id=1467706 ====================================================================== ---------------------------------------------------------------------- (0007571) kern (administrator) - 2017-07-11 11:13 http://bugs.bacula.org/view.php?id=2294#c7571 ---------------------------------------------------------------------- What a mess. So now MariaDB is no longer compatible with MySQL, and so we have a new database to maintain! ?? I need to discuss this a bit and see what we are going to do. I'm not really enthusiastic in supporting another database, but in this case, I suspect that we have no choice -- it is already a lot of work with two databases (MySQL Postgresql). To be clear, for the moment we do not support MariaDB unless it is "identical" to MySQL, which it has been. My complaints are not directed at you, but rather at the general state of affairs. Thanks for reporting this. I'll get back to you on this. Can you tell me what the official position of RedHat/Fedora on MySQL vs MariaDB is? or where I can find it? ---------------------------------------------------------------------- (0007572) slaanesh (reporter) - 2017-07-12 07:46 http://bugs.bacula.org/view.php?id=2294#c7572 ---------------------------------------------------------------------- MariaDB is the default database for both Fedora and Red Hat Enterprise Linux variants. They stopped supporting MySQL long time ago (around Fedora 19 it became the default, so that's quite a few years now). It is also shipped as backports in various releases as part of RHEL Software Collections. Fedora 27 (due in 6 months) will be ship MariaDB 10.2 by default and all packages in the distro will use the libraries provided by it. After that, it will go sooner or later in a RHEL release as default and as a backport in a Software Collection for older RHEL releases. There is the bug link above just to keep track of the programs that have problem building with Maria DB 10.2, so they can be sorted out before pushing 10.2 in the official Fedora repositories. ---------------------------------------------------------------------- (0007573) kern (administrator) - 2017-07-12 14:03 http://bugs.bacula.org/view.php?id=2294#c7573 ---------------------------------------------------------------------- Did you make a patch to correct the "libmysqlclient.so" to "libmariadb.so" change. If so, I would appreciate a link to it or that you post it so I can see what you did. Can you point me to an iso that I could install here with a distro that has MariaDB 10.2 available? If I can bring Bacula up on a system, I think I can find a quick solution and maybe resolve this for 9.0.1. ---------------------------------------------------------------------- (0007575) kern (administrator) - 2017-07-12 19:24 http://bugs.bacula.org/view.php?id=2294#c7575 ---------------------------------------------------------------------- The prior note has been deleted and replaced by this corrected version. I found out how to install MariaDB 10.2 on Ubuntu 16.04 (Xenial), which is what I generally use. The strange thing is that on Ubuntu, Bacula 9.0.1 compiles and links perfectly well with MariaDB 10.2. I had purged MySQL, so I am about 99.9% sure that it is not picking up MySQL. Perhaps Debian/Ubuntu have solved the MySQL/MariaDB 10.2 compatibility problem. However, the regression scripts seem to fail, most likely due to some probably between Bacula and MariaDB. ---------------------------------------------------------------------- (0007576) kern (administrator) - 2017-07-13 08:49 http://bugs.bacula.org/view.php?id=2294#c7576 ---------------------------------------------------------------------- Yesterday I downloaded MariaDB 10.2.7 from the mariadb.org web site and as I noted in my prior post, it builds perfectly fine with Bacula 9.0.1 on Ubuntu 16.04. Consequently, at this moment, this bug seems to be something to do with the RedHat/Fedora version of MariaDB 10.2. Perhaps you have an older version and the problems you ran into have been subsequently fixed. However, version 10.2.7 of MariaDB has a lock detection bug that cause Bacula Jobs to fail. This bug does not exist on older versions of MariaDB that I have tried, nor does it exist on the current Ubuntu 16.04 of MySQL. Unfortunately, mariadb.org seems to have no bug reporting possibility for the community. The problem shows up in the Bacula three-pool-virtual-test regression test and produces the following error: localhost-dir: sql_create.c:837-5 Fill File table Query failed: INSERT INTO File (FileIndex, JobId, PathId, FilenameId, LStat, MD5, DeltaSeq) SELECT batch.FileIndex, batch.JobId, Path.PathId, Filename.FilenameId,batch.LStat, batch.MD5, batch.DeltaSeq FROM batch JOIN Path ON (batch.Path = Path.Path) JOIN Filename ON (batch.Name = Filename.Name): ERR=Deadlock found when trying to get lock; My conclusion is that MariaDB 10.2.7 is not ready for production use, so please be cautioned. If you know how I can submit a bug report to mariadb.org, please let me know, and I will submit one. ---------------------------------------------------------------------- (0007581) kern (administrator) - 2017-07-17 09:33 http://bugs.bacula.org/view.php?id=2294#c7581 ---------------------------------------------------------------------- This is just to let you know that I have filed a bug report with MariaDB, and they have responded, so they are interested. I have given them all the information they should need to reproduce the bug. For reference this is the link to the MariaDB bug report: https://jira.mariadb.org/browse/MDEV-13333 ---------------------------------------------------------------------- (0007582) slaanesh (reporter) - 2017-07-18 11:24 http://bugs.bacula.org/view.php?id=2294#c7582 ---------------------------------------------------------------------- Still not able to build for Fedora, MariaDB 10.2.7 has been pushed to the repositories. I'm pretty surprised you don't hit the problem. There is a regression open on MariaDB: https://jira.mariadb.org/browse/MDEV-12950 Maybe Ubuntu is carrying some patch in the MariaDB build? Most projects are hitting exactly the same error and are applying patches: https://github.com/jabberd2/jabberd2/pull/152/commits/2ffb3a3edaddf55c1465301de8f297545da59db8 https://github.com/PyMySQL/mysqlclient-python/pull/177/commits/d663649f851794dffa84010db6290e693d4baab8 ---------------------------------------------------------------------- (0007583) kern (administrator) - 2017-07-19 08:32 http://bugs.bacula.org/view.php?id=2294#c7583 ---------------------------------------------------------------------- The MySQL person who is handling the error that I reported has pointed me to a RedHat proposed fix for this problem of the "reconnect" variable. I will test it in the next few days. However, it is my view that it is a regression in MariaDB. If the strategy is to maintain compatibility with MySQL, then it really should be MariaDB that fixes the problem, though at the same time, I will try to fix it for Bacula as well. The same goes for the renamed shared object. If the object is compatibility, then it is a MariaDB bug. If compatibility is no longer desired, it would help me and probably other developers to get information on exactly how to detect that MariaDB is running (preferably independent of the distro). Also, a list of all the incompatibilities would help ensure that we can adapt our programs to MariaDB. I am not excited about supporting another database, but if that is the future, I will adapt to it. ---------------------------------------------------------------------- (0007584) kern (administrator) - 2017-07-20 16:37 http://bugs.bacula.org/view.php?id=2294#c7584 ---------------------------------------------------------------------- Two updates. 1. I have applied a fix (same as the RedHat one) for the reconnect bug, and will push it to the repo once I have tested it a bit more. 2. Also MariaDB has reproduced the "deadlock" bug that causes intermittent Bacula Job failures with MariaDB 10.7.2 ---------------------------------------------------------------------- (0007585) kern (administrator) - 2017-07-20 18:45 http://bugs.bacula.org/view.php?id=2294#c7585 ---------------------------------------------------------------------- Fixed the reconnect bug and pushed the new code to the repo. Issue History Date Modified Username Field Change ====================================================================== 2017-07-11 09:01 slaanesh New Issue 2017-07-11 11:13 kern Status new => feedback 2017-07-11 11:13 kern Note Added: 0007571 2017-07-12 07:46 slaanesh Note Added: 0007572 2017-07-12 07:46 slaanesh Status feedback => new 2017-07-12 14:03 kern Status new => feedback 2017-07-12 14:03 kern Note Added: 0007573 2017-07-12 19:24 kern Note Added: 0007575 2017-07-13 08:49 kern Note Added: 0007576 2017-07-17 09:33 kern Note Added: 0007581 2017-07-18 11:24 slaanesh Note Added: 0007582 2017-07-18 11:24 slaanesh Status feedback => new 2017-07-19 08:32 kern Status new => confirmed 2017-07-19 08:32 kern Note Added: 0007583 2017-07-20 16:37 kern Note Added: 0007584 2017-07-20 18:45 kern Status confirmed => closed 2017-07-20 18:45 kern Resolution open => fixed 2017-07-20 18:45 kern Note Added: 0007585 ====================================================================== |
From: Mantis B. T. <no...@bu...> - 2017-07-20 15:37:41
|
A NOTE has been added to this issue. ---------------------------------------------------------------------- (0007584) kern (administrator) - 2017-07-20 16:37 http://bugs.bacula.org/view.php?id=2294#c7584 ---------------------------------------------------------------------- Two updates. 1. I have applied a fix (same as the RedHat one) for the reconnect bug, and will push it to the repo once I have tested it a bit more. 2. Also MariaDB has reproduced the "deadlock" bug that causes intermittent Bacula Job failures with MariaDB 10.7.2 ---------------------------------------------------------------------- |
From: Mantis B. T. <no...@bu...> - 2017-07-19 07:32:47
|
The following issue has been CONFIRMED. ====================================================================== http://bugs.bacula.org/view.php?id=2294 ====================================================================== Reported By: slaanesh Assigned To: ====================================================================== Project: Bacula Bug Reports Issue ID: 2294 Category: sql Reproducibility: always Severity: major Priority: normal Status: confirmed ====================================================================== Date Submitted: 2017-07-11 09:01 BST Last Modified: 2017-07-19 08:32 BST ====================================================================== Summary: Unable to build with Maria DB 10.2 Description: MariaDB 10.2 introduce some changes, including a rename from "libmysqlclient.so" to "libmariadb.so". This is the result when compiling the recent Bacula 9.0.0 release with Maria DB 10.2: Making libbacsql.la ... /builddir/build/BUILD/bacula-9.0.0/libtool --silent --tag=CXX --mode=link /usr/bin/g++ -Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -o libbacsql.la bvfs.lo cats.lo sql.lo sql_cmds.lo sql_create.lo sql_delete.lo sql_find.lo sql_get.lo sql_list.lo sql_update.lo -export-dynamic -rpath /usr/lib64 -release 9.0.0 mysql.c: In member function 'virtual bool BDB_MYSQL::bdb_open_database(JCR*)': mysql.c:261:20: error: 'MYSQL {aka struct st_mysql}' has no member named 'reconnect' mdb->m_instance.reconnect = 1; /* so connection does not timeout */ ^~~~~~~~~ make[1]: *** [Makefile:183: mysql.lo] Error 1 make[1]: *** Waiting for unfinished jobs.... Steps to Reproduce: Compile against MariaDB 10.2. Additional Information: Originally reported here: https://bugzilla.redhat.com/show_bug.cgi?id=1467706 ====================================================================== ---------------------------------------------------------------------- (0007571) kern (administrator) - 2017-07-11 11:13 http://bugs.bacula.org/view.php?id=2294#c7571 ---------------------------------------------------------------------- What a mess. So now MariaDB is no longer compatible with MySQL, and so we have a new database to maintain! ?? I need to discuss this a bit and see what we are going to do. I'm not really enthusiastic in supporting another database, but in this case, I suspect that we have no choice -- it is already a lot of work with two databases (MySQL Postgresql). To be clear, for the moment we do not support MariaDB unless it is "identical" to MySQL, which it has been. My complaints are not directed at you, but rather at the general state of affairs. Thanks for reporting this. I'll get back to you on this. Can you tell me what the official position of RedHat/Fedora on MySQL vs MariaDB is? or where I can find it? ---------------------------------------------------------------------- (0007572) slaanesh (reporter) - 2017-07-12 07:46 http://bugs.bacula.org/view.php?id=2294#c7572 ---------------------------------------------------------------------- MariaDB is the default database for both Fedora and Red Hat Enterprise Linux variants. They stopped supporting MySQL long time ago (around Fedora 19 it became the default, so that's quite a few years now). It is also shipped as backports in various releases as part of RHEL Software Collections. Fedora 27 (due in 6 months) will be ship MariaDB 10.2 by default and all packages in the distro will use the libraries provided by it. After that, it will go sooner or later in a RHEL release as default and as a backport in a Software Collection for older RHEL releases. There is the bug link above just to keep track of the programs that have problem building with Maria DB 10.2, so they can be sorted out before pushing 10.2 in the official Fedora repositories. ---------------------------------------------------------------------- (0007573) kern (administrator) - 2017-07-12 14:03 http://bugs.bacula.org/view.php?id=2294#c7573 ---------------------------------------------------------------------- Did you make a patch to correct the "libmysqlclient.so" to "libmariadb.so" change. If so, I would appreciate a link to it or that you post it so I can see what you did. Can you point me to an iso that I could install here with a distro that has MariaDB 10.2 available? If I can bring Bacula up on a system, I think I can find a quick solution and maybe resolve this for 9.0.1. ---------------------------------------------------------------------- (0007575) kern (administrator) - 2017-07-12 19:24 http://bugs.bacula.org/view.php?id=2294#c7575 ---------------------------------------------------------------------- The prior note has been deleted and replaced by this corrected version. I found out how to install MariaDB 10.2 on Ubuntu 16.04 (Xenial), which is what I generally use. The strange thing is that on Ubuntu, Bacula 9.0.1 compiles and links perfectly well with MariaDB 10.2. I had purged MySQL, so I am about 99.9% sure that it is not picking up MySQL. Perhaps Debian/Ubuntu have solved the MySQL/MariaDB 10.2 compatibility problem. However, the regression scripts seem to fail, most likely due to some probably between Bacula and MariaDB. ---------------------------------------------------------------------- (0007576) kern (administrator) - 2017-07-13 08:49 http://bugs.bacula.org/view.php?id=2294#c7576 ---------------------------------------------------------------------- Yesterday I downloaded MariaDB 10.2.7 from the mariadb.org web site and as I noted in my prior post, it builds perfectly fine with Bacula 9.0.1 on Ubuntu 16.04. Consequently, at this moment, this bug seems to be something to do with the RedHat/Fedora version of MariaDB 10.2. Perhaps you have an older version and the problems you ran into have been subsequently fixed. However, version 10.2.7 of MariaDB has a lock detection bug that cause Bacula Jobs to fail. This bug does not exist on older versions of MariaDB that I have tried, nor does it exist on the current Ubuntu 16.04 of MySQL. Unfortunately, mariadb.org seems to have no bug reporting possibility for the community. The problem shows up in the Bacula three-pool-virtual-test regression test and produces the following error: localhost-dir: sql_create.c:837-5 Fill File table Query failed: INSERT INTO File (FileIndex, JobId, PathId, FilenameId, LStat, MD5, DeltaSeq) SELECT batch.FileIndex, batch.JobId, Path.PathId, Filename.FilenameId,batch.LStat, batch.MD5, batch.DeltaSeq FROM batch JOIN Path ON (batch.Path = Path.Path) JOIN Filename ON (batch.Name = Filename.Name): ERR=Deadlock found when trying to get lock; My conclusion is that MariaDB 10.2.7 is not ready for production use, so please be cautioned. If you know how I can submit a bug report to mariadb.org, please let me know, and I will submit one. ---------------------------------------------------------------------- (0007581) kern (administrator) - 2017-07-17 09:33 http://bugs.bacula.org/view.php?id=2294#c7581 ---------------------------------------------------------------------- This is just to let you know that I have filed a bug report with MariaDB, and they have responded, so they are interested. I have given them all the information they should need to reproduce the bug. For reference this is the link to the MariaDB bug report: https://jira.mariadb.org/browse/MDEV-13333 ---------------------------------------------------------------------- (0007582) slaanesh (reporter) - 2017-07-18 11:24 http://bugs.bacula.org/view.php?id=2294#c7582 ---------------------------------------------------------------------- Still not able to build for Fedora, MariaDB 10.2.7 has been pushed to the repositories. I'm pretty surprised you don't hit the problem. There is a regression open on MariaDB: https://jira.mariadb.org/browse/MDEV-12950 Maybe Ubuntu is carrying some patch in the MariaDB build? Most projects are hitting exactly the same error and are applying patches: https://github.com/jabberd2/jabberd2/pull/152/commits/2ffb3a3edaddf55c1465301de8f297545da59db8 https://github.com/PyMySQL/mysqlclient-python/pull/177/commits/d663649f851794dffa84010db6290e693d4baab8 ---------------------------------------------------------------------- (0007583) kern (administrator) - 2017-07-19 08:32 http://bugs.bacula.org/view.php?id=2294#c7583 ---------------------------------------------------------------------- The MySQL person who is handling the error that I reported has pointed me to a RedHat proposed fix for this problem of the "reconnect" variable. I will test it in the next few days. However, it is my view that it is a regression in MariaDB. If the strategy is to maintain compatibility with MySQL, then it really should be MariaDB that fixes the problem, though at the same time, I will try to fix it for Bacula as well. The same goes for the renamed shared object. If the object is compatibility, then it is a MariaDB bug. If compatibility is no longer desired, it would help me and probably other developers to get information on exactly how to detect that MariaDB is running (preferably independent of the distro). Also, a list of all the incompatibilities would help ensure that we can adapt our programs to MariaDB. I am not excited about supporting another database, but if that is the future, I will adapt to it. Issue History Date Modified Username Field Change ====================================================================== 2017-07-11 09:01 slaanesh New Issue 2017-07-11 11:13 kern Status new => feedback 2017-07-11 11:13 kern Note Added: 0007571 2017-07-12 07:46 slaanesh Note Added: 0007572 2017-07-12 07:46 slaanesh Status feedback => new 2017-07-12 14:03 kern Status new => feedback 2017-07-12 14:03 kern Note Added: 0007573 2017-07-12 19:24 kern Note Added: 0007575 2017-07-13 08:49 kern Note Added: 0007576 2017-07-17 09:33 kern Note Added: 0007581 2017-07-18 11:24 slaanesh Note Added: 0007582 2017-07-18 11:24 slaanesh Status feedback => new 2017-07-19 08:32 kern Status new => confirmed 2017-07-19 08:32 kern Note Added: 0007583 ====================================================================== |
From: Mantis B. T. <no...@bu...> - 2017-07-18 10:24:21
|
A NOTE has been added to this issue. ---------------------------------------------------------------------- (0007582) slaanesh (reporter) - 2017-07-18 12:24 http://bugs.bacula.org/view.php?id=2294#c7582 ---------------------------------------------------------------------- Still not able to build for Fedora, MariaDB 10.2.7 has been pushed to the repositories. I'm pretty surprised you don't hit the problem. There is a regression open on MariaDB: https://jira.mariadb.org/browse/MDEV-12950 Maybe Ubuntu is carrying some patch in the MariaDB build? Most projects are hitting exactly the same error and are applying patches: https://github.com/jabberd2/jabberd2/pull/152/commits/2ffb3a3edaddf55c1465301de8f297545da59db8 https://github.com/PyMySQL/mysqlclient-python/pull/177/commits/d663649f851794dffa84010db6290e693d4baab8 ---------------------------------------------------------------------- |