<div dir="ltr"><div>Hey Ian,</div><div><br></div><div>I'm not sure if this is the best fix for the problem. But here's a patch that makes ksudoku not copy the xml file before loading it into QDomDocument, just loads it where it is instead. This fixes the issue here, but you probably have a reason for having the copyjob in there. Let me know if I can test anything else etc.</div><div><br></div><div>BR,</div><div>Jeremy<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 19, 2019 at 10:36 AM Jeremy Whiting <<a href="mailto:jpwhiting@kde.org">jpwhiting@kde.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">I'm not sure why gmail's reply to all isn't putting you in Ian... Anyway, the cause is the QDomDocument::setContent from the QTemporaryFile after it copies the file out of the installation path (why is that needed by the way?) Adding some debugging to the call it seems the error is "Unexpected end of file" on line 1 column 1. I checked the file does exist and such, I wonder if the download copy job is leaving the QTemporaryFile object's seek point at the end of the file as it writes it or something. No, adding a tmpFile.reset() before setting the content does not help. It's as if the copy job finishes before the file is written to disk. I don't have any weird mount options (or any, since /tmp/ is just part of my / partition here). Not sure what's going on to cause QDomDocument::setContent to think the file is empty...<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 18, 2019 at 9:53 PM Ian Wadham <<a href="mailto:iandw.au@gmail.com" target="_blank">iandw.au@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> On 19 Mar 2019, at 2:24 pm, Jeremy Whiting <<a href="mailto:jpwhiting@kde.org" target="_blank">jpwhiting@kde.org</a>> wrote:<br>
> <br>
> I'll see what I can figure out. no problem. Albert are you building with kdesrc-build ? or manually? I'm using kdesrc-build buliding into /usr/local. Until this morning libkdegames didn't build because I was missing libsndfile, after adding that I'm seeing the same failure described by Duncan in the bug. I'll debug it tomorrow and see what's causing it.<br>
<br>
The variants that fail are all those whose rules are defined by XML files in ksudoku/src/shapes<br>
— and only those variants. The failure point in KSudoku appears to be exactly where it calls the<br>
loadCustomShape method in the sudoku::Serializer code. See details in<br>
    <a href="https://bugs.kde.org/show_bug.cgi?id=405422#c3" rel="noreferrer" target="_blank">https://bugs.kde.org/show_bug.cgi?id=405422#c3</a><br>
<br>
My guess is that some newer version of XML parsing libraries dislikes KSudoku’s XML files or<br>
possibly that some changed XML version or DOCTYPE has got into the act.<br>
<br>
Ian W.<br>
<br>
> BR,<br>
> Jeremy<br>
> <br>
> On Mon, Mar 18, 2019 at 4:52 PM Albert Astals Cid <<a href="mailto:aacid@kde.org" target="_blank">aacid@kde.org</a>> wrote:<br>
> El dilluns, 18 de març de 2019, a les 20:44:06 CET, Jeremy Whiting va escriure:<br>
> > Yep, same thing happens here. Aztec -> Generate A Puzzle shows a dialog box<br>
> > that says "<br>
> > <br>
> > Unable to generate a puzzle of the chosen variant; please try another."<br>
> > with a build I just did.<br>
> <br>
> Weird, works just fine for me.<br>
> <br>
> Jeremy guess it's on you to debug it :/<br>
> <br>
> Cheers,<br>
>   Albert<br>
> <br>
> > <br>
> > <br>
> > BR,<br>
> > <br>
> > Jeremy<br>
> > <br>
> > On Thu, Mar 14, 2019 at 9:24 PM Ian Wadham <<a href="mailto:iandw.au@gmail.com" target="_blank">iandw.au@gmail.com</a>> wrote:<br>
> > <br>
> > > It appears that KSudoku is failing catastrophically. Only the most vanilla<br>
> > > puzzle types can be selected<br>
> > > (i.e.  Classic Sudoku nxn and Roxdoku nxnxn). All others fail to create<br>
> > > their data-structures from XML<br>
> > > files and so fail to generate a puzzle and display it (e.g. XSudoku,<br>
> > > Killer Sudoku, Aztec, Samurai<br>
> > > and many more).<br>
> > ><br>
> > > For more details, please see <a href="https://bugs.kde.org/show_bug.cgi?id=405422" rel="noreferrer" target="_blank">https://bugs.kde.org/show_bug.cgi?id=405422</a>,<br>
> > > especially comment #3.<br>
> > ><br>
> > > This was reported by Duncan, who builds KF5 and apps from live-git and has<br>
> > > just noticed the problem<br>
> > > appearing in the last week or two --- more recently than any changes in<br>
> > > the KSudoku source.<br>
> > ><br>
> > > Please can someone who has access to builds and executables of the latest<br>
> > > development (HEAD)<br>
> > > KSudoku code check if they can reproduce this error? You just need to run<br>
> > > KSudoku, select Aztec<br>
> > > puzzle-type (for example) and click on “Generate A Puzzle”.<br>
> > ><br>
> > > Thanks in advance,<br>
> > > Ian Wadham.<br>
> > ><br>
> > ><br>
> > <br>
> <br>
> <br>
> <br>
> <br>
<br>
</blockquote></div>
</blockquote></div>