Bug#959957: A quick fix for this bug
Hi! Here is a patch that fixes ctags invocation problem with the latest Kate. Basically it reverts QProcess::start() call to its previous form which should be acceptable for Qt 5.12, 5.14. A complete solution is more complicated - Kate should split a command line and provide ctags arguments to Qt library as a list (QStringList). For me, this situation looks a little bit strange - now a part of library functionality which was available for quite a long time is moved from the library itself to an application using that library... fix-ctags-command.patch Description: Binary data
Bug#959957: kate: Kate ctags addon does not start ctag process to update database
Package: kate
Version: 4:20.04.0-1
Severity: normal
Tags: upstream
Dear Maintainer,
After updating to the latest Kate, I have noticed that cgit no longer
updates its tag database when I press "Update Index" button. Instead, it
produces a message box:
Failed to run "ctags -R -f /home/di/
/home/di/ ". exitStatus = 0
After Kate source code examination I have found this upstream commit:
https://github.com/KDE/kate/commit/30bde6d47a8727347f6deaa4b318669d078f85d2
"Port some deprecated method in qt5.15"
Among other things, it has changed the way Kate is starting cgit process:
QString command = QStringLiteral("%1 -f %2
%3").arg(m_ctagsUi.cmdEdit->text(), m_ctagsUi.tagsFile->text(), targets);
-m_proc.start(command);
+m_proc.start(command, QStringList());
According to Qt documentation, in this version of QProcess::start(...),
"No further splitting of the arguments is performed".
https://doc.qt.io/qt-5.12/qprocess.html#start
At the same time, ctags command is still prepared together with its
arguments as one string! So ctags addon is essentially broken by this
commit, and it's not fixed yet in upstream.
My proposal is to create a patch for debian which will restore an old
method call - it should work fine as long as Debian is using Qt 5.12/5.14
and upstream Kate is not fixed.
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 5.6.0-1-amd64 (SMP w/16 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages kate depends on:
ii kate5-data 4:20.04.0-1
ii kio 5.62.1-2+b1
ii ktexteditor-katepart 5.62.0-1+b1
ii libc62.30-4
ii libkf5bookmarks5 5.62.0-1+b1
ii libkf5completion55.62.0-1+b1
ii libkf5configcore55.62.0-1+b1
ii libkf5configgui5 5.62.0-1+b1
ii libkf5configwidgets5 5.62.0-1+b1
ii libkf5coreaddons55.62.0-1
ii libkf5crash5 5.62.0-1+b1
ii libkf5dbusaddons55.62.0-1
ii libkf5guiaddons5 5.62.0-2
ii libkf5i18n5 5.62.0-1
ii libkf5jobwidgets55.62.0-1+b1
ii libkf5kiocore5 5.62.1-2+b1
ii libkf5kiofilewidgets55.62.1-2+b1
ii libkf5kiowidgets55.62.1-2+b1
ii libkf5newstuff5 5.62.0-1+b1
ii libkf5parts5 5.62.0-1+b1
ii libkf5plasma55.62.0-2
ii libkf5service-bin5.62.0-1
ii libkf5service5 5.62.0-1
ii libkf5syntaxhighlighting55.62.0-3
ii libkf5texteditor55.62.0-1+b1
ii libkf5textwidgets5 5.62.0-1+b1
ii libkf5threadweaver5 5.62.0-1
ii libkf5wallet-bin 5.62.0-1+b1
ii libkf5wallet55.62.0-1+b1
ii libkf5widgetsaddons5 5.62.0-1+b1
ii libkf5windowsystem5 5.62.0-3
ii libkf5xmlgui55.62.0-1+b1
ii libqt5core5a 5.12.5+dfsg-10
ii libqt5dbus5 5.12.5+dfsg-10
ii libqt5gui5 5.12.5+dfsg-10
ii libqt5sql5 5.12.5+dfsg-10
ii libqt5widgets5 5.12.5+dfsg-10
ii libqt5xml5 5.12.5+dfsg-10
ii libstdc++6 10-20200418-1
ii plasma-framework 5.62.0-2
ii qml-module-org-kde-kquickcontrolsaddons 5.62.0-1+b2
ii qml-module-qtquick-layouts 5.12.5-5
ii qml-module-qtquick2 5.12.5-5
Versions of packages kate recommends:
ii sonnet-plugins 5.62.0-1+b1
Versions of packages kate suggests:
pn darcs
ii exuberant-ctags 1:5.9~svn20110310-13
ii git 1:2.26.2-1
ii khelpcenter 4:18.04.0-1+b1
ii konsole-kpart4:19.08.1-2+b1
pn mercurial
ii subversion 1.13.0-4
-- no debconf information
Bug#836903: RFS: qevercloud/3.0.2+ds-1 [ITP] -- Unofficial Evernote Cloud API library for Qt
Hello, I am the upstream developer of QEverCloud library. Sorry for the interference, I'd just like to clarify a bit what QEverCloudGenerator is and how it is intended to work. Let me start from a brief description of how Thrift IDL - interface definition language - works. It is a pseudo-programming-language "optimized" for the definition of interfaces for structures and functions. There's a tool called thrift compiler which can generate the source code in various actually existing programming languages from the definition in the form of Thrift IDL files. The entire thrift project is currently maintained by the Apache Software Foundation - https://thrift.apache.org. Apache's thrift compiler can produce the C++ source code from Thrift IDL files. However, the resulting C++ code is quite inconvenient to use along with Qt framework due to having to use non-Qt data types along with Qt data types - it results in having to do numerous conversions between these data types which adds to runtime overhead and overall complexity. QEverCloudGenerator is an ad-hoc tool meant to replace the thrift compiler for the particular case of Evernote Thrift IDL files, to generate more Qt-friendly C++ code i.e. the code using Qt data types where possible/feasible. The key word is "ad-hoc". It was not developed to become another backend of the official thrift compiler which is a much more complex task than solving a particular use case of generating some code from a few particular Thrift IDL files using only a subset of allowed Thrift IDL constructs. As such, QEverCloudGenerator can't be considered a general purpose Thrift compiler generating the Qt-friendly C++ code. Evernote people have recently released the Thrift IDL files for the new version of their API - https://github.com/evernote/evernote-thrift/pull/6. Currently QEverCloudGenerator cannot handle the updated Thrift IDL files as the subset of allowed Thrift IDL constructs has been extended compared to the previous version of API. I am in the process of making it able to handle these new files. And unless QEverCloudGenerator becomes the general purpose thrift compiler backend some day, the necessity for the similar procedures should generally be expected to for future Evernote API releases. Regards, Dmitry Ivanov. On Thu, 8 Sep 2016 06:36:48 +0800 Boyuan Yang <073p...@gmail.com> wrote: > 2016-09-08 0:52 GMT+08:00 Sean Whitton <spwhit...@spwhitton.name>: > > The issue is that then we then have multiple copies of the thrift files > > in Debian: a copy in each source package that needs them, either for > > regeneration or in debian/missing-sources/. > > > > Suppose there is an Evernote protocol change, or some other bug that > > means the thrift files get updated. If there is one copy of them in > > Debian, we just update that, and then binNMU all the packages that use > > it, and we're done. > > Unfortunately things will not be the case, at least not for Evernote thrift > files. > > I had some discussions to the current maintainer of QEverCloud about > the possibility of updating thrift IDL files and regenerate again. > https://github.com/d1vanov/QEverCloud/issues/5 > > He just told me it is not possible, since the generator needs to be > updated. Update in Evernote thrift files will simply leads to FTBFS > without the update in the generator. > > > Otherwise, if there are lots of copies, we have to update each package > > separately. That's significantly more work, and can't be done by just > > one person, but needs the involvement of the maintainers of all those > > packages. > > > > This is especially relevant if we need to update the thrift files in a > > Debian stable release: updates to packages in a released version of > > Debian have to go through a careful vetting procedure, and this means we > > only have to do that once. That saves a lot of time (and indeed makes > > it feasible at all). > > > > It's possible I've misunderstood the purpose of the thrift files, though > > -- if there was an Evernote API change, they would have to change and > > the corresponding language-specific generators re-run, right? > > In this specific case, we also need to notice the slow evolvement of > Evernote Cloud API (>= 3 years, longer than Debian stable release cycle. > Take a look at Evernote official SDK) > and the backward compatibility of the API. Not updating API will not cause > problems, and it is the author of program (i.e., nixnote2 author) who has > the responsibility to update the level of API itself uses. Even if the Evernote > API is updated according to the new thrift files by packagers, the added methods > will not be utilized until the program author decide to switch to the > new API, and > the changed/removed methods
Bug#504721: Console broken on SunFire V120
Hello! I'm trying to install Debian on SunFire V120. I can see installer menu but it does not respond to any keypresses. My boot.img is from here: http://http.us.debian.org/debian/dists/lenny/main/installer-sparc/current/images/netboot/ Modified on 19-Oct-2008. We're not going to use this server in production anymore. It is available for testing if it could help to fix this bug. -- Dmitry Ivanov Network engineer +371 67788235 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
