[okular] [Bug 267350] filling out a PDF form saves data to some file i ~/.kde/share/apps/okular/docdata/
https://bugs.kde.org/show_bug.cgi?id=267350 Ross Boylan changed: What|Removed |Added CC||ross.boy...@ucsf.edu --- Comment #51 from Ross Boylan --- (In reply to lutz.wrage from comment #50) > Is there any use case that justifies storing form data in > ~/.kde/share/apps/okular/docdata/ given that the same data can be stored in > the pdf itself? > It seems to me that there isn't. While I consider the current behavior undesirable, it does have its advantages. In fact, it's the reason I decided to use okular for my taxes. Here's the use case: 1. Generate some forms automatically (e.g., opentaxsolver computes my taxes and fills in government forms). 2. Resulting forms require some manual tweaks (e.g., check boxes, fill in additional fields). 3. Discover forms need to be regenerated to correct a mistake. Modify inputs and return to 1. In this scenario, the work in 2 is lost if the results have been stored in the pdf, but is retained if the values are stored elsewhere, as okular currently does. Even if the pdf in 2 is saved under a different name, so that the results are not literally lost, one must manually identify the changed information and reenter it. There is another scenario in which the recreation of the information is less desirable. If some of the manually entered information in 2 depends on the values from 1, e.g., you manually enter line 55 as a copy of line 32 but the automatically generated line 32 changes, then the previous manual data may be invalid. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 267350] filling out a PDF form saves data to some file i ~/.kde/share/apps/okular/docdata/
https://bugs.kde.org/show_bug.cgi?id=267350 --- Comment #52 from Ross Boylan --- I don't want my previous response to be taken as a vote for the status quo. The behavior I would expect is: 1. If I don't hit save my work disappears.(*) The current application does not have a save function (as distinct from save as), and I'm pretty sure that if I fill in a form, exit, and then open the form my old values will still be there. Worse, if someone else using the same account opens the form, they will see my info. 2. If I do save (not just save as) my work will be saved with the file. In this case I might not expect, but would be pleased if 3. there were an option to save the form data to a separate file and restore it from a separate file. I'd guess such a facility is consistent with the 1600 page XFA spec, though I can't say I know where :) Because the current behavior violates these expectations, it is a security risk. Someone's personal information may be exposed in ways unanticipated, and operations that usually assure security, like not saving a file or deleting it, will not work. And operations that are expected to reveal info, like copying/mailing a pdf or operating on it with a different program, may instead conceal/disappear the information. (*) Some usability experts argue that "work disappears if I don't save" is not the expectation of the lay user, and that our current model of "you must save to keep your work" is aggravating and unintuitive to them. That may well be correct. But unless the surrounding programs all start behaving this way, this behavior is undesirable. An application that may be dealing with sensitive private information is not the place to pioneer new interface models. -- You are receiving this mail because: You are watching all bug changes.
[partitionmanager] [Bug 462611] New: Info on how to get started using KPMcore library is incomplete
https://bugs.kde.org/show_bug.cgi?id=462611 Bug ID: 462611 Summary: Info on how to get started using KPMcore library is incomplete Classification: Applications Product: partitionmanager Version: Git Platform: Debian stable OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: andr...@stikonas.eu Reporter: ross.boy...@ucsf.edu Target Milestone: --- SUMMARY Please provide enough information in README.md to use the library. DETAILS The Initialization section provides some scraps of code, but not a complete working example. I have so far been unable to make the transition. Here are the issues I've encountered: 1. `Device` not declared in this scope. Solution: add `#include ` 2. `backend` not declared in this scope. I've tried a lot of variations to get it; none have worked. `CoreBackendManager.h` says ``` * This is basically a singleton class to give the application access to the currently * selected backend and also to manage the available backend plugins. ``` But my latest variation, `QList devices = CoreBackendManager()->backend()->scanDevices(false);`, yields ``` build] ../test.cpp: In function ‘int main(int, char**)’: [build] ../test.cpp:32:49: error: ‘CoreBackendManager::CoreBackendManager()’ is private within this context [build]32 | QList devices = CoreBackendManager()->backend()->scanDevices(false); [build] | ^ [build] In file included from ../test.cpp:6: [build] /usr/include/kpmcore/backend/corebackendmanager.h:34:5: note: declared private here [build]34 | CoreBackendManager(); [build] | ^~ [build] ../test.cpp:32:49: error: ‘CoreBackendManager::~CoreBackendManager()’ is private within this context [build]32 | QList devices = CoreBackendManager()->backend()->scanDevices(false); [build] | ^ [build] In file included from ../test.cpp:6: [build] /usr/include/kpmcore/backend/corebackendmanager.h:35:5: note: declared private here [build]35 | ~CoreBackendManager(); [build] | ^ [build] ../test.cpp:32:50: error: base operand of ‘->’ has non-pointer type ‘CoreBackendManager’ [build]32 | QList devices = CoreBackendManager()->backend()->scanDevices(false); ``` This code gets called after the suggested `initKPMcore`, though since this is a compile-time error that may not matter. CMAKE PROBLEMS I had lots of trouble getting the test project to find the right include files with `CMake`, mostly because I overlooked the steps you did document in the `README`. But one part of the instructions seemed odd, the requirement to explicitly add the include path. The [tutorial](https://community.kde.org/Guidelines_and_HOWTOs/CMake/Frameworks) says that adding an explicit link target will automatically take care of includes: "This [that is the target_link_libraries declaration] will not only link the tutorial target against the KArchive library, it will set up the include paths properly as well." Is there a reason that pattern doesn't apply here (I tried; the link declaration alone definitely is insufficient)? VERSIONS My test code is running against the development libraries packaged for Debian bullseye, libkpmcore1020.12.3-2, though I've mostly been looking at the source from git. -- You are receiving this mail because: You are watching all bug changes.
[partitionmanager] [Bug 462611] Info on how to get started using KPMcore library is incomplete
https://bugs.kde.org/show_bug.cgi?id=462611 --- Comment #1 from Ross Boylan --- Also, I would expect there to be some master include file, e.g., `#include ` that would get the whole library. It is unclear if such a file exists, or what it's called. -- You are receiving this mail because: You are watching all bug changes.
[partitionmanager] [Bug 462611] Info on how to get started using KPMcore library is incomplete
https://bugs.kde.org/show_bug.cgi?id=462611 --- Comment #3 from Ross Boylan --- Thanks for the pointer. That was the last bit I needed, and I can now compile and run. Qt structures are impenetrable in the debugger, but that's a separate issue. I'm installing kdevelop and qtcreator now; I think both have helpers for debugging. So my final tips to get running were 1. Use CoreBackendManager::self()->backend() to get the backend. 2. The app requires the Qt event loop, which can be started with QCoreApplication app(argc, argv); 3. Those require including and -- You are receiving this mail because: You are watching all bug changes.
[partitionmanager] [Bug 462611] Info on how to get started using KPMcore library is incomplete
https://bugs.kde.org/show_bug.cgi?id=462611 --- Comment #4 from Ross Boylan --- By the way, continuing on your remarks that kpmcore isn't a regular library, when I went to file a bug I noticed there was no entry for it under KDE Frameworks; there is one for partitionmanager under Applications. This might also be related to why no API documentation appears on the web. -- You are receiving this mail because: You are watching all bug changes.
[partitionmanager] [Bug 462087] New: What API documentation?
https://bugs.kde.org/show_bug.cgi?id=462087 Bug ID: 462087 Summary: What API documentation? Classification: Applications Product: partitionmanager Version: Git Platform: Other OS: All Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: andr...@stikonas.eu Reporter: ross.boy...@ucsf.edu Target Milestone: --- SUMMARY *** https://invent.kde.org/system/kpmcore/-/blob/master/README.md says, under the "Using KPMCore" section > Most of the usage information on KPMcore is included in the API documentation Where is that API documentation? *** EXPECTED RESULT I expected that the reference would include a link to a place I could view that documentation online. Absent a link, I figured I could find such documentation with a web search; I've searched, but haven't turned up anything. Absent any of that, I thought there might be instructions for how to build such documentation from the source code. I haven't found that either. I expected that "API Documentation" referred to something other than reading the header files. ADDITIONAL INFORMATION I'm not too familiar with building KDE software or its documentation system; perhaps at least my last place fallback (build it myself) is something that would be apparent if I were. I did spend a little time looking for such information and didn't find it. -- You are receiving this mail because: You are watching all bug changes.
[kdiff3] [Bug 405506] New: Needs specific instructions about how to build from source
https://bugs.kde.org/show_bug.cgi?id=405506 Bug ID: 405506 Summary: Needs specific instructions about how to build from source Product: kdiff3 Version: 1.8.x Platform: unspecified OS: MS Windows Status: REPORTED Severity: normal Priority: NOR Component: application Assignee: reeves...@gmail.com Reporter: ross.boy...@ucsf.edu Target Milestone: --- SUMMARY Please describe specifically how to build the package from source on Windows or *nix. Ideally this would go in INSTALL; alternately it could go in the README. This would start with a list of prerequisite software, where to obtain it, and whether source or binary versions were necessary. It would then describe environment setup and build steps. DETAILS The current source code (git://anongit.kde.org/kdiff3.git) does not explain in any specific way how to build the package on either Windows (my current concern) or *nix. INSTALL is simply a pointer to the README, which has some general remarks about requirements at the top. The old, specific, instructions were deleted as obsolete, but they haven't been replaced by anything. It doesn't even indicate which specific KF5 frameworks are required. Maybe this is all obvious to those familiar with cmake or KF5, but it's not obvious to me. The old INSTALL recipe of configure; make; make install was "obvious" to those familiar with it, but it was still documented in INSTALL. I'm hoping for something similar. https://community.kde.org/Guidelines_and_HOWTOs/Build_from_source/Windows has been only marginally helpful. Having followed the steps, I'm not even sure if I've completed them properly or not (the last thing was the message Execute: C:\Program Files (x86)\Microsoft Visual Studio\Shared\Python37_64\python.exe c:\Users\rdboylan\Documents\src\CraftRoot\craft-master\bin\craft.py craft Please ensure that you have installed the C++ component ). And it was also unclear to me from those instructions whether it would suffice to download the Qt binaries. -- You are receiving this mail because: You are watching all bug changes.
[Craft] [Bug 405662] New: Add MSVS 2019 support + fix nits
https://bugs.kde.org/show_bug.cgi?id=405662 Bug ID: 405662 Summary: Add MSVS 2019 support + fix nits Product: Craft Version: master Platform: MS Windows OS: MS Windows Status: REPORTED Severity: wishlist Priority: NOR Component: Core Assignee: vonr...@kde.org Reporter: ross.boy...@ucsf.edu CC: kde-wind...@kde.org Target Milestone: --- SUMMARY Please add support for MS Visual Studio 2019, currently available in preview and RC and scheduled for release April 2 (https://devblogs.microsoft.com/visualstudio/visual-studio-2019-release-candidate-rc-now-available/) Along the way I encountered some documentation and error handling that I think can be improved on. STEPS TO REPRODUCE 1. Following https://community.kde.org/Guidelines_and_HOWTOs/Build_from_source/Windows setup powershell and start installation. 2. The script asks to choose a compiler and MSVS 2019 is not on the list. That completes the steps to reproduce. I pressed on, selecting MSVS 2017, which is not on my system. OBSERVED RESULT VS2019 was not a choice. After continuing with 2017 I got the message Execute: C:\Program Files (x86)\Microsoft Visual Studio\Shared\Python37_64\python.exe c:\Users\rdboylan\Documents\src\CraftRoot\craft-master\bin\craft.py craft Please ensure that you have installed the C++ component and it stopped. EXPECTED RESULT Well, I kind of expected it to fail :) But it would have been nice if it didn't. I also expected it would be clear whether or not the installation succeeded; it was not. That is, the final message sounded as if it could be recommended post-installation setup. It was also very unclear what exactly was being referred to. Based on looking at the code I'm pretty sure this was a failure. The likely immediate cause was that VCTOOLSREDISTDIR was not set. This was partly because the instructions noted above do not refer to it until AFTER the instructions to install craft. Whether setting it will be sufficient to proceed I don't know; I'll try as soon as I figure the best way to restart. In short: 1. Main issue: Add support for VS 2019 Secondary issues: 2. If installation fails, make it clear it has failed. 3. The message "Please ensure that you have installed the C++ component" could be more explicit about what exactly is missing and how it needs to be installed. 4. Instructions at https://community.kde.org/Guidelines_and_HOWTOs/Build_from_source/Windows should specify steps in the order in which they are performed, i.e., set env variables before running script. Better yet, the script could handle this itself, minimally by warning if a needed environment variable is missing and maximally by setting it appropriately. FWIW, I believe with my current installation C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\VC\Redist\MSVC\14.20.27404 is the right value. I believe $env:VCTOOLSREDISTDIR= "..." is the right way to set it. SOFTWARE/OS VERSIONS Windows: 10 64 bit; MSVS 2019 Preview ADDITIONAL INFORMATION Note the installer did find the Python3.7 that was installed as part of VS. I was doing this to build kdiff3. -- You are receiving this mail because: You are watching all bug changes.
[Craft] [Bug 405662] Add MSVS 2019 support + fix nits
https://bugs.kde.org/show_bug.cgi?id=405662 --- Comment #1 from Ross Boylan --- After a lot of hacking, I have changes that might be appropriate. I still haven't a completely successful install, but the reasons appear unrelated. What is the best way to communicate the changes? They are in a branch in git in my local machine; I cloned from github, but I thought I read that is read-only. Some of the changes permit identification of pre-release versions of MSVS, which are otherwise invisible. Ross -- You are receiving this mail because: You are watching all bug changes.
[Craft] [Bug 405662] Add MSVS 2019 support + fix nits
https://bugs.kde.org/show_bug.cgi?id=405662 --- Comment #3 from Ross Boylan --- See https://phabricator.kde.org/D19933 for the patch. -- You are receiving this mail because: You are watching all bug changes.
[Craft] [Bug 405909] New: Unclear instructions at end of craft setup
https://bugs.kde.org/show_bug.cgi?id=405909 Bug ID: 405909 Summary: Unclear instructions at end of craft setup Product: Craft Version: master Platform: MS Windows OS: MS Windows Status: REPORTED Severity: normal Priority: NOR Component: Core Assignee: vonr...@kde.org Reporter: ross.boy...@ucsf.edu CC: kde-wind...@kde.org Target Milestone: --- SUMMARY Instructions presented to the user about what to do at the end of the craft installation are unclear and sometimes contradictory. SPECIFICS 1. CraftBootrap.py's last message is "Please run the following command to get started:". It is unclear whether the indicated command needs to be run once to complete the installation, or needs to be run at the start of every session using craft. Inspection of the code shows some things that are clearly one-time moves, and others that might not be. 2. craftenv.psl, the script to be run has these comments in the header: #this file sets some environment variables that are needed #for finding programs and libraries etc. #by Hannah von Reth #you should copy CraftSettings.ini.template to ..\etc\CraftSettings.ini #and adapt it to your needs (see that file for more info) a) There is no CraftSettings.ini.template file that I can see b) The script itself moves, not copies, kdesettings.ini to CraftSettings.ini c) The instructions to adapt it to your needs are invisible unless you look at the file. d) "this file sets some environment variables" suggests the script should be run in each powershell session 3. craftenv.psl clears the screen. This was a surprise to me, leading me to lose the record of the installation that preceded it. Perhaps don't clear the screen, or ask first. 4. CraftSettings.ini itself is well-commented. I found the [QtSDK] section a bit weird since it had an uncommented Path referring to a non-existent drive, Version referring to an earlier version than I believe the installer downloaded, and Compiler set to mingw even though I selected msvc. I assume none of this matters since Enabled = False in this section. 5. https://community.kde.org/Guidelines_and_HOWTOs/Build_from_source/Windows a) The section on installing craft makes no mention of running the environment setup or customizing the ini file. b) The section on using craft says to run the environment setup. I take that as another indication it needs to be run every session. c) The note at the end of the installing craft section, "Note: For Microsoft Visual Studio compiler, it's necessary to have VCTOOLSREDISTDIR." actually refers to steps that must be taken *before* step 3. For us non-powershell gurus, it would be helpful to indicate how to do this in powershell. I hope the answer is $Env:VCTOOLSREDISTDIR = "somepath" d) The section "Using the stock Qt SDK" likewise appears after the installation instructions, but I guess needs to be done earlier if it is to be done at all. I found this whole section somewhat confusing, though my take-away was "don't do this; it might cause trouble." It sounded as if Qt would end up installed through other means. SOFTWARE/OS VERSIONS Windows: 10 ADDITIONAL INFORMATION Setup was for VS2017. -- You are receiving this mail because: You are watching all bug changes.
[Craft] [Bug 405910] New: Bad pointer for bug submission
https://bugs.kde.org/show_bug.cgi?id=405910 Bug ID: 405910 Summary: Bad pointer for bug submission Product: Craft Version: master Platform: MS Windows OS: MS Windows Status: REPORTED Severity: normal Priority: NOR Component: Core Assignee: vonr...@kde.org Reporter: ross.boy...@ucsf.edu CC: kde-wind...@kde.org Target Milestone: --- SUMMARY https://github.com/KDE/craft has a link for bugs that doesn't lead to any obvious way to submit bugs. STEPS TO REPRODUCE 1. Go to https://github.com/KDE/craft 2. Scroll down to the "Getting in Touch" section at the bottom 3. Click on the "Report Bugs" link. OBSERVED RESULT End up at https://phabricator.kde.org/project/profile/61/ which has no obvious way to submit a bug. EXPECTED RESULT End up somewhere I can submit a bug, presumably bugs.kde.org. Ideally it would be partly filled out. Or, the page I arrived at could have a clear way to submit bugs. I gather phabricator will do bug tracking in the future, but for now it doesn't. As a stopgap, it might at least include a link to bugs.kde.org. SOFTWARE/OS VERSIONS Windows: 10 ADDITIONAL INFORMATION The hyperlink is in the README.md file. -- You are receiving this mail because: You are watching all bug changes.
[kdiff3] [Bug 405918] New: INSTALL instructions don't work
https://bugs.kde.org/show_bug.cgi?id=405918 Bug ID: 405918 Summary: INSTALL instructions don't work Product: kdiff3 Version: 1.8.x Platform: MS Windows OS: MS Windows Status: REPORTED Severity: normal Priority: NOR Component: application Assignee: reeves...@gmail.com Reporter: ross.boy...@ucsf.edu Target Milestone: --- SUMMARY INSTALL instructions don't work. Build fails to find the first package and gives up. STEPS TO REPRODUCE 1. Installed craft on Win 10 with MSVC 2017. 2. Followed new INSTALL instructions from https://cgit.kde.org/kdiff3.git/tree/INSTALL (blob: 88471cbe3d4c11007abf253ee9c60c54ad0a2287). Since I'd already followed most of the steps (except I did not use Admin privileges, and CraftRoot was in my local directory hierarchy). This came down to executing ... 3. Craft --package kdiff3 OBSERVED RESULT PS C:\Users\rdboylan\Documents\src\CraftRoot> Craft --package kdiff3 Craft : C:\Users\rdboylan\Documents\src\CraftRoot Version : master ABI : windows-msvc2017_64-cl Download directory : C:\Users\rdboylan\Documents\src\CraftRoot\download === *** Handling package: extragear/kdiff3, action: package *** *** Action: package for extragear/kdiff3 *** could not find installed nsis package, 'craft nsis' Action: package for extragear/kdiff3:master FAILED *** Craft package failed: extragear/kdiff3 after 1 second *** PS C:\Users\rdboylan\Documents\src\CraftRoot> EXPECTED RESULT Download and build all required packages. I thought craft would always fetch packages it didn't find; I'm not sure why it just gave up. SOFTWARE/OS VERSIONS Windows: 10 ADDITIONAL INFORMATION MSVS 2019 Preview is also on the system. The craft setup appeared to have been successful, but this is the first time I've used it for anything other than building itself. craft has some local modifications to support VS2019; I don't think they are material for this scenario. Thank you for providing the INSTALL document in response to my earlier request. -- You are receiving this mail because: You are watching all bug changes.
[kdiff3] [Bug 405918] INSTALL instructions don't work
https://bugs.kde.org/show_bug.cgi?id=405918 --- Comment #3 from Ross Boylan --- craft kdiff3 did a lot more, but had a hiccup along the way and then a heart attack: Hiccup: *** Craft all succeeded: libs/dbus after 5 seconds *** === *** Handling package: binary/mysql, action: all *** *** Action: fetch-binary for binary/mysql *** wget https://files.kde.org/craft/master/Qt_5.12.2/windows/msvc2017_64/cl/RelWithDebInfo/binary/mysql/mysql-5.7.18-7-20190319T110634-windows-msvc2017_64-cl.7z C:/Users/rdboylan/Documents/src/CraftRoot/downl 100%[==>] 60.38M 17.5MB/sin 3.3s executing command: C:\Users\rdboylan\Documents\src\CraftRoot\dev-utils\bin\7za.exe x -r -y -oC:\Users\rdboylan\Documents\src\CraftRoot\build\binary\mysql\image-RelWithDebInfo-5.7.18 C:\Users\rdboylan\Documents\src\CraftRoot\download\cache\Qt_5.12.2\windows\msvc2017_64\cl\RelWithDebInfo\binary\mysql\mysql-5.7.18-7-20190319T110634-windows-msvc2017_64-cl.7z -t7z -bso2 -bsp1 executing command: C:\Users\rdboylan\Documents\src\CraftRoot\bin\mysqld.exe --console --initialize-insecure mysqld: Could not create or access the registry key needed for the MySQL application to log to the Windows EventLog. Run the application with sufficient privileges once to create the key, add the key manually, or turn off logging for that application. 2019-03-29T21:44:15.689166Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details). 2019-03-29T21:44:15.690169Z 0 [ERROR] Cannot open Windows EventLog; check privileges, or start server with --log_syslog=0 2019-03-29T21:44:18.180819Z 0 [Warning] InnoDB: New log files created, LSN=45790 2019-03-29T21:44:18.823955Z 0 [Warning] InnoDB: Creating foreign key constraint system tables. 2019-03-29T21:44:19.129020Z 0 [Warning] No existing UUID has been found, so we assume that this is the first time that this server has been started. Generating a new UUID: ce849c47-526b-11e9-aca6-b88584b6a8d5. 2019-03-29T21:44:19.225276Z 0 [Warning] Gtid table is not ready to be used. Table 'mysql.gtid_executed' cannot be opened. 2019-03-29T21:44:19.233296Z 1 [Warning] root@localhost is created with an empty password ! Please consider switching off the --initialize-insecure option. *** Craft all succeeded: binary/mysql after 1 minute 18 seconds *** === Comments: 1) Running without elevated privileges seems the likely immediate cause; 2) But it seems odd that elevated privileges should be required for what I understand to be a build form source step; 3) It's unclear to me what the status is at the end. On the one hand, there is [ERROR} in the middle of the log. On the other hand the final message indicates success. At any rate, execution continued for quite awhile. But then *** Craft all succeeded: kde/frameworks/tier1/kcodecs after 15 seconds *** === *** Handling package: libs/boost/boost-headers, action: all *** *** Action: fetch-binary for libs/boost/boost-headers *** *** libs/boost/boost-headers not found in cache *** *** Action: fetch for libs/boost/boost-headers *** wget https://dl.bintray.com/boostorg/release/1.69.0/source/boost_1_69_0.tar.gz C:/Users/rdboylan/Documents/src/CraftRoot/downl 100%[==>] 106.53M 41.6MB/sin 2.6s *** Action: unpack for libs/boost/boost-headers *** Failed to unpack boost_1_69_0.tar.gz Traceback (most recent call last): File "C:\Users\rdboylan\Documents\src\CraftRoot\craft\bin\utils.py", line 86, in unpackFile shutil.unpack_archive(os.path.join(downloaddir, filename), workdir) File "C:\Program Files (x86)\Microsoft Visual Studio\Shared\Python37_64\lib\shutil.py", line 999, in unpack_archive func(filename, extract_dir, **kwargs) File "C:\Program Files (x86)\Microsoft Visual Studio\Shared\Python37_64\lib\shutil.py", line 934, in _unpack_tarfile tarobj.extractall(extract_dir) File "C:\Program Files (x86)\Microsoft Visual Studio\Shared\Python37_64\lib\tarfile.py", line 2002, in extractall numeric_owner=numeric_owner) File "C:\Program Files (x86)\Microsoft Visual Studio\Shared\Python37_64\lib\tarfile.py", line 2044, in extract numeric_owner=numer
[kdiff3] [Bug 405918] INSTALL instructions don't work
https://bugs.kde.org/show_bug.cgi?id=405918 --- Comment #5 from Ross Boylan --- I enabled developer mode and reran. First time failed with PermissionError: [WinError 5] Access is denied: 'C:\\Users\\rdboylan\\Documents\\src\\CraftRoot\\build\\_\\20653f50\\boost_1_69_0\\libs' I made sure I had nothing open on the directory tree and tried again. I still got FileNotFoundError: [Errno 2] No such file or directory: 'C:\\Users\\rdboylan\\Documents\\src\\CraftRoot\\build\\_\\20653f50\\boost_1_69_0\\libs\\geometry\\doc\\html\\geometry\\reference\\spatial_indexes\\boost__geometry__index__rtree\\rtree_parameters_type_constindexable_getter_constvalue_equal_constallocator_type_const___.html' Do I need to delete the directory (which?)? Restart powershell after having set dev mode (don't think so: tried it and got the 2nd error above)? Do some equivalent of make clean, hopefully one that will only affect boost-headers? Except for the problem with qith MySQL, the stuff before this all seems to have built OK. Does that fact I was not in dev mode means some of those packages might not be quite right either? Ross From: Hannah von Reth Sent: Friday, March 29, 2019 4:34 PM To: Boylan, Ross Subject: [kdiff3] [Bug 405918] INSTALL instructions don't work https://bugs.kde.org/show_bug.cgi?id=405918 Hannah von Reth changed: What|Removed |Added CC||vonr...@kde.org --- Comment #4 from Hannah von Reth --- For the boost tar. Please enable Windows dev mode https://protect2.fireeye.com/url?k=9f8ede37-c3ceb361-9f8ef92a-0cc47adb57f0-5e9fc5eb173cc7c9&u=https://docs.microsoft.com/en-us/windows/uwp/get-started/enable-your-device-for-development so that symlinks are supported(then we can use 7z to unpack stuff) -- You are receiving this mail because: You reported the bug. -- You are receiving this mail because: You are watching all bug changes.
[kdiff3] [Bug 405918] INSTALL instructions don't work
https://bugs.kde.org/show_bug.cgi?id=405918 --- Comment #7 from Ross Boylan --- I deleted both the boost folder and the one above it, 20653f50. This did allow the build to continue. After > 30 minutes it finished, showing success. The next step fails, however, in the same way it did before. craft --package kdiff3: === *** Handling package: extragear/kdiff3, action: package *** *** Action: package for extragear/kdiff3 *** could not find installed nsis package, 'craft nsis' Action: package for extragear/kdiff3:master FAILED *** Craft package failed: extragear/kdiff3 after 0 seconds *** cs kdiff3 does seem to put me in the source directory, which looks like a git repo. cb kdiff3 puts me in a subdirectory, and from there bin\kdiff3 launches the program! Yea! Ross From: Hannah von Reth Sent: Saturday, March 30, 2019 2:06:41 AM To: Boylan, Ross Subject: [kdiff3] [Bug 405918] INSTALL instructions don't work https://bugs.kde.org/show_bug.cgi?id=405918 --- Comment #6 from Hannah von Reth --- Can you try to manually delete the boost folder? Looks like some bad files, created from the failed fallback unpack. -- You are receiving this mail because: You reported the bug. -- You are receiving this mail because: You are watching all bug changes.
[kdiff3] [Bug 405918] INSTALL instructions don't work
https://bugs.kde.org/show_bug.cgi?id=405918 --- Comment #9 from Ross Boylan --- Well, the message just says a package isn't installed. The immediate point is that the install instructions for kdiff3 are still incomplete. I don't know if it's a kdiff3 or, more likely, a craft issue, but it seems odd that craft doesn't go ahead and install the package nsis. If the intent of the message from craft was that I should execute 'craft nsis', that is not clear. That phrase currently reads as an appositive for "nsis package" NOT as an instruction. Admittedly it doesn't quite make sense in that reading. On the theory that it was intended as an instruction (which for some reason craft --package didn't want to execute) I executed 'craft nsis' and then repeated the craft --package command. I think this worked. So does the line Output: "C:\Users\rdboylan\Documents\src\CraftRoot\tmp\kdiff3-prefilter-b794c83-windows-msvc2017_64-cl.exe" mean that file is an installer for the kdiff3 I previously built? Here's the transcript of the final, --package, step: == *** Handling package: extragear/kdiff3, action: package *** *** Action: package for extragear/kdiff3 *** Overriding C:\Users\rdboylan\Documents\src\CraftRoot\build\extragear\kdiff3\archive\bin\data\info\dir Overriding C:\Users\rdboylan\Documents\src\CraftRoot\build\extragear\kdiff3\archive\bin\data\info\dir executing command: C:\Users\rdboylan\Documents\src\CraftRoot\dev-utils\bin\7za.exe a -r C:\Users\rdboylan\Documents\src\CraftRoot\tmp\kdiff3-prefilter-b794c83-windows-msvc2017_64-cl.7z -bso2 -bsp1 C:\Users\rdboylan\Documents\src\CraftRoot\build\extragear\kdiff3\archive\* executing command: C:\Users\rdboylan\Documents\src\CraftRoot\dev-utils\bin\7za.exe a -r C:\Users\rdboylan\Documents\src\CraftRoot\tmp\kdiff3-prefilter-b794c83-windows-msvc2017_64-cl-dbg.7z -bso2 -bsp1 C:\Users\rdboylan\Documents\src\CraftRoot\build\extragear\kdiff3\archive-dbg\* executing command: C:\Users\rdboylan\Documents\src\CraftRoot\dev-utils\bin\makensis.exe /V3 C:\Users\rdboylan\Documents\src\CraftRoot\build\_\51b6ca1c\kdiff3.nsi MakeNSIS v3.03 - Copyright 1999-2018 Contributors See the file COPYING for license details. Credits can be found in the Users Manual. Processing config: C:\Users\rdboylan\Documents\src\CraftRoot\dev-utils\nsis\nsisconf.nsh Processing script file: "C:\Users\rdboylan\Documents\src\CraftRoot\build\_\51b6ca1c\kdiff3.nsi" (ACP) Processed 1 file, writing output (x86-ansi): Output: "C:\Users\rdboylan\Documents\src\CraftRoot\tmp\kdiff3-prefilter-b794c83-windows-msvc2017_64-cl.exe" Install: 6 pages (384 bytes), 2 sections (1 required) (4144 bytes), 822 instructions (23016 bytes), 295 strings (5369 bytes), 1 language table (334 bytes). Uninstall: 2 pages (192 bytes), 1 section (2072 bytes), 328 instructions (9184 bytes), 163 strings (2735 bytes), 1 language table (254 bytes). Datablock optimizer saved 1888 bytes (~0.0%). Using zlib compression. EXE header size: 63488 / 37888 bytes Install code: 5929 / 31663 bytes Install data: 74342779 / 75050374 bytes Uninstall code+data: 24201 / 28522 bytes CRC (0x3C024D03): 4 / 4 bytes Total size: 74436401 / 75148451 bytes (99.0%) *** Craft package succeeded: extragear/kdiff3 after 5 minutes 14 seconds *** -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 267350] filling out a PDF form saves data to some file i ~/.kde/share/apps/okular/docdata/
https://bugs.kde.org/show_bug.cgi?id=267350 Ross Boylan changed: What|Removed |Added CC||ross.boy...@ucsf.edu --- Comment #51 from Ross Boylan --- (In reply to lutz.wrage from comment #50) > Is there any use case that justifies storing form data in > ~/.kde/share/apps/okular/docdata/ given that the same data can be stored in > the pdf itself? > It seems to me that there isn't. While I consider the current behavior undesirable, it does have its advantages. In fact, it's the reason I decided to use okular for my taxes. Here's the use case: 1. Generate some forms automatically (e.g., opentaxsolver computes my taxes and fills in government forms). 2. Resulting forms require some manual tweaks (e.g., check boxes, fill in additional fields). 3. Discover forms need to be regenerated to correct a mistake. Modify inputs and return to 1. In this scenario, the work in 2 is lost if the results have been stored in the pdf, but is retained if the values are stored elsewhere, as okular currently does. Even if the pdf in 2 is saved under a different name, so that the results are not literally lost, one must manually identify the changed information and reenter it. There is another scenario in which the recreation of the information is less desirable. If some of the manually entered information in 2 depends on the values from 1, e.g., you manually enter line 55 as a copy of line 32 but the automatically generated line 32 changes, then the previous manual data may be invalid. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 267350] filling out a PDF form saves data to some file i ~/.kde/share/apps/okular/docdata/
https://bugs.kde.org/show_bug.cgi?id=267350 --- Comment #52 from Ross Boylan --- I don't want my previous response to be taken as a vote for the status quo. The behavior I would expect is: 1. If I don't hit save my work disappears.(*) The current application does not have a save function (as distinct from save as), and I'm pretty sure that if I fill in a form, exit, and then open the form my old values will still be there. Worse, if someone else using the same account opens the form, they will see my info. 2. If I do save (not just save as) my work will be saved with the file. In this case I might not expect, but would be pleased if 3. there were an option to save the form data to a separate file and restore it from a separate file. I'd guess such a facility is consistent with the 1600 page XFA spec, though I can't say I know where :) Because the current behavior violates these expectations, it is a security risk. Someone's personal information may be exposed in ways unanticipated, and operations that usually assure security, like not saving a file or deleting it, will not work. And operations that are expected to reveal info, like copying/mailing a pdf or operating on it with a different program, may instead conceal/disappear the information. (*) Some usability experts argue that "work disappears if I don't save" is not the expectation of the lay user, and that our current model of "you must save to keep your work" is aggravating and unintuitive to them. That may well be correct. But unless the surrounding programs all start behaving this way, this behavior is undesirable. An application that may be dealing with sensitive private information is not the place to pioneer new interface models. -- You are receiving this mail because: You are watching all bug changes.
