Activity for Rok Mandeljc
-
Rok Mandeljc committed [2668ba] on GIT
libMirage: MirageFragment: fix description and annotations
-
libMirage: gobject-introspection: update deprecated `allow-none` annotations
-
libMirage: gobject-introspection: fix incorrect `closure` annotations
-
cmake: bump minimum CMake version
-
libMirage: MDS parser: fix num_layers detection
-
gCDEmu: debian dir from official DEB package
-
vhba: Debian version 20250329-1
-
libMirage: Debian version 3.2.10-1
-
vhba: Bump DEB package Standards-Version
-
vhba: DEB package compatible with debhelper <= 12
-
Bump versions for next (partial) release
-
vhba: debian: add missing releases to appstream info
-
libMirage: debian: add missing releases to appstream info
-
libMirage: writer: adjust detection of pregap-only fragments
-
libMirage: ISO writer: fix segfault when track has no associated filename
-
I'll see about pushing a new release tomorrow or over the weekend. Thanks for the reminder!
-
Thanks for the heads up! I've pushed commit ee6bba585d53891577089e9dd856eb733d8231f8 which should fix this.
-
VHBA: fix building with kernel 6.14-rc1
-
libMirage: READCD parser: clear prev_mode when opening new session
-
vhba: debian dir from official DEB package
-
libMirage: debian dir from official DEB package
-
image analyzer: debian dir from DEB package
-
Daemon: debian dir from official DEB package
-
Client: debian dir from official DEB package
-
Bump versions for next (partial) release
-
vhba: fix build errors with kernel 6.11
-
Determine session type when parsing cuesheets
-
Bump versions for next (partial) release
-
Fix previous session's last track size when creating new session (cue)
-
VHBA does not compile with kernel 6.11
-
This was fixed in vhba-module-20240917.
-
That does look more in line with other reports. To clarify - you do not only have vhba module loaded, but also have at least one cdemu-daemon instance running, and at least one virtual device created? Or not (i.e, just vhba module loaded, and nothing else). Also, do you have any other optical drives (internal or external) connected to the system? The number of in-flight number reported fordisk_events_workfn seems suspiciously high. I think this is related to kernel's continuous probing for device...
-
We've had couple of issue reports over years with suspend/hibernate (https://sourceforge.net/p/cdemu/bugs/91, https://github.com/cdemu/cdemu/issues/11), and I've seen couple of threads around the internet where vhba and cdemu were identified as culprit. I haven't been able to reproduce these locally, though. Suspend on my Fedora 40 notebook (6.10.4-200.fc40.x86_64 #1 SMP PREEMPT_DYNAMIC) seems to work as expected. Although with caveat that the default suspend method here seems to be deep, while s2idle,...
-
We've had couple of issue reports with suspend/hibernate (https://sourceforge.net/p/cdemu/bugs/91, https://github.com/cdemu/cdemu/issues/11), and I've seen couple of threads around the internet where vhba and cdemu were identified as culprit. I haven't been able to reproduce these locally, though. Suspend on my Fedora 40 notebook (6.10.4-200.fc40.x86_64 #1 SMP PREEMPT_DYNAMIC) seems to work as expected. Although with caveat that the default suspend method here seems to be deep, and s2idle, which...
-
Daemon: adjust error codes returned by read commands
-
Daemon: implement SEEK (10) command
-
Daemon: READ SUBCHANNEL command fixes
-
vhba: bump version for new release
-
vhba: make all module's functions static
-
Those are issues with 2nd and higher-order dependencies, and have nothing to do with our packages. I don't see them when trying to build in bookworm/trixie/sid containers, so I guess it's a problem with your system. Maybe you need to update package list ("apt update")? Or perhaps upgrade all packages to the latest available version (assuming you are using trixie or sid).
-
Debian 12 Testing - only vhba compiles
-
Those are issues with 2nd and higher-order dependencies, and have nothing to do with our packages. I don't see them when trying to build in bookworm/trixie/sid containers, so I guess it's a problem with your system. Maybe you need to update package list ("apt update")?
-
Seems to build just fine under both stable (12) and testing (13). How are you installing those dependencies? Usually the easiest way is to use "apt build-dep ." from the source directory.
-
Fails to build against linux-6.8 due to -Werror and upstream commit
-
Should be fixed in vhba-module-20240202 (tested on Fedora Rawhide with 6.8.0-0.rc0.20240112git70d201a40823.5.fc40.x86_64).
-
Thanks for the heads-up! Looks like most (if not all) of functions in the vhba module should be static in the first place...
-
Illegal Audio-MPEG-Header 0x00000000 at offset 2104 (libmpg123) using image with audio tracks
-
Should be fixed in libmirage 3.2.7.
-
gCDEmu: CMake: add missing whitespace
-
Bump versions for next (partial) release
-
libMirage: SNDFILE filter: ignore .BIN files
-
libMirage: SNDFILE filter: fix signalling of read errors
-
image analyzer: fix compatibility with matplotlib 3.8
-
vhba module: debian: add dh-dkms to build dependencies
-
debian scripts: bump debhelper compatibility level to 10
-
The auto-start scripts provided with cdemu-daemon (>= 3.2.5) are written for systemd-based systems. If you want to use auto-start on a system that does not use systemd (such as MX Linux; at least the XFCE spin), you will have to set it up yourself. See https://sourceforge.net/p/cdemu/code/ci/27bfe4b1368fec8557c5ae34e47d40a207dc1188/ When you ran the daemon manually, what makes you think it was stuck? It is running in the foreground, and because it is a daemon, it is running forever... Either way,...
-
Bump versions for next (partial) release
-
libMirage: remove two-character patterns from apple disk image MIME
-
Daemon: use g_memdup2 with GLib 2.68 or newer
-
libMirage: use g_memdup2 with GLib 2.68 or newer
-
vhba: fix kernel version check for scsi_done()
-
vhba: fix kernel version check for scsi_done()
-
Bump versions for next (partial) release
-
vhba: fix build errors for kernel 5.15
-
debian: Add alternative dependency gir1.2-ayatanaappindicator3-0.1.
-
gCDEmu: If no AppIndicator3 is available try to load AyatanaAppIndicator3.
-
Daemon: debian: remove dh-systemd build dependency
-
Daemon: debian: add dbus-user-session to list of dependencies
-
Bump versions for next release
-
debian: update requirements
-
Modernize and clean up CMake files
-
Daemon: update README
-
Daemon: update man page
-
Daemon: debian: adjust debian build scripts for new service files
-
Daemon: remove bundled DBus activation scripts
-
Daemon: allow specified config file to be non-existant
-
Daemon: implement built-in config file parser
-
Daemon: use G_OPTION_ARG_FILENAME for --logfile argument
-
Daemon: audio playback: minor clean up
-
Join the old playback thread after playback finish or error.
-
Daemon: replace use of DAEMON_DEBUG_ERROR with DAEMON_DEBUG_WARNING
-
libMirage: MirageWriter: disambiguate open_image() method
-
libMirage: docs: fix missing link warnings
-
libMirage: docs: add docs for look-up tables
-
libMirage: docs: add the unused entries to libmirage-sections.txt
-
libMirage: fixed the header path for Vala bindings
-
libmirage: Allow generating Vala bindings
-
libMirage: NRG parser: avoid using strlen() to determine if MCN/ISRC is set
-
libMirage: NRG parser: do not try to validate/set empty ISRC
-
Pacstall
-
Nope, we'll stick to our Launchpad PPA for the project's "official" Ubuntu support. As with all packaging efforts, feel free to set up the packages on Pacstall yourself if you think it is worth it...
-
I have no idea why gi suddenly moved from python3 to python 3.5 which is clearly what the problem was. gi didn't move anywhere - it is exactly where it was from the very beginning. Your distribution provides deb packages for python 3.5 it packages, which is also the default python3 for that distribution. So initially, things worked because python3 pointed to system python 3.5 that had gi installed. Then someone installed python3.6 on that system (placed in /usr/local), and made it the default python3...
-
OK, so do you see what your problem is? You are using a distribution that has python 3.5.3 as the packaged python version, and so the gi that is packaged in python3-gi is installed for that python (into /usr/lib/python3/dist-packages/gi, as per https://packages.debian.org/stretch/amd64/python3-gi/filelist). Your system, however, is using python 3.6.3 as its default python, and therefore does not have gi available. So you can either: a) install gi for your python 3.6.3 b) make python 3.5.3 the default...
-
What is the output of dpkg -s python3? And what do you get if you run python3, then run: import sys print(sys.path)
-
So as you can see, gi is not available in your python 3.6.3, which cdemu is using. When you say gi is installed, what exactly is installed? Do you have python3-specific package installed (on regular debian that would be python3-gi)?
-
What distribution, what python version, how did you install cdemu? Is the gobject introspection installed in the same python environment that cdemu is using? Try launching python manually, using the shebang from /usr/local/bin/cdemu (i.e., the first line in the file - for example, "/usr/bin/env python3") and do "import gi" there...
-
XMLWriter: always export values at maximum required precision
-
No, there is no support for restoring previous session.
-
Looks like that version of gir-scanner cannot handle non-ascii characters in the paths. Either try unpacking the source somewhere else, or disable GObject introspection if you don't need it.
-
Build Vala bindings
1 >
