A commit a122984 adds symbol list. This list includes internal APIs. They're:

hinawa_context_add_src@Base 0.6.0
hinawa_context_remove_src@Base 0.6.0

If possible, I'd like to remove them from out packaging routine.

This issue is similar to #22

N:    The extended description (the lines after the first line of the
N:    "Description:" field) is only one or two lines long. The extended
N:    description should provide a user with enough information to decide
N:    whether they want to install this package, what it contains, and how it
N:    compares to similar packages. One or two lines is normally not enough to
N:    do this.
N:    
N:    Refer to Debian Developer's Reference section 6.2.1 (General guidelines
N:    for package descriptions) and Debian Developer's Reference section 6.2.3
N:    (The long description) for details.
N:    
N:    Severity: minor, Certainty: possible
N:    

In GLib convention, the function with GError should return gboolean to report error.

• https://docs.gtk.org/glib/error-reporting.html

Current libhinawa provides functions which does not follow to the convention.

I maintain versioning of this package by a scheme below:

package version = major.minor.micro

so that:

• major: updated when losing backward compatibility.
• minor: updated when any new object or property for gobject are added.
• micro: updated when any changes of code except for the above; e.g. bug fixes.

In libtool fashion, versioning of library interface is decided by this scheme. Practically, this guideline is suggested. The version is described with three parts:

iface version = current:revision:age

so that:

• current: The most recent interface number that this library implements.
• revision: The implementation number of the current interface.
• age: The difference between the newest and oldest interfaces that this library implements.

Then, at present, I maintain versioning of library interface for libtool by a scheme below:

iface version = (minor * 10 + micro):(major):(minor * 10 + micro)

The relationship between versions of package/iface/binary is described in this fugure:

For our information, suffix of binary file might be decided by libtool according to this formula:

.so.x.y.z = .so.(current - age).(age).(revision)

Well, at present, I have a plan to add changes with loss of backward compatibility and I'm working for updating major version to 1. Then, according to my formula, the relationship is described in this fugure:

The current field of iface version declines to zero. This loses convention of library interface because the value of current field should be increased monotonically. I need to fix it.

Let's try to discuss about Intent To Package.

• Wait until 0.7.0 release because of lisence issue.

I want to support cryptographic signature verification in next package update.

ref. https://wiki.debian.org/debian/watch#Cryptographic_signature_verification

Here is the summary:

Upstream:

• upload a signed file (such as libhinawa-0.7.0.tar.gz.asc)

gpg2 --local-user XXX --armor --detach-sign  libhinawa-0.7.0.tar.gz

Packager:

• add debian/upstream/signing-key.asc
• update debian/watch to support pgpsigurlmangle option

Currently libhinawa will be shipped under LGPL v2.1, while backport.h comes from Linux kernel userspace application programming interface (UAPI) header and is licensed under GPL v2. (see include/uapi/sound/firewire.h in Linux kernel source.)

Furthermore, this library depends on GLib and GObject, thus runtimes are linked to them automatically. They are licensed under GPL v2. In this case, even if libhinawa is licensed under LGPL v2.1, userspace applications of libhinawa should be licensed under GPL v2. As a result, it seems to have no effectives that libhinawa is licensed under LGPLv2.

Totally, I think it better to change licensing for libhinawa to GPLv2.

In Linux 4.5 or before, snd-firewire-tascam module doesn't support mmap/munmap yet. Thus, this functionality should be removed from libhinawa 0.7.0.

This causes SndTscm.open() failure.

Linux kernel version 5.6 supports hardware time stamp of asynchronous communication which FireWire subsystem newly provides. It requires user space application to set new version of UAPI and dispatch additional events which delivers the time stamp. The time stamp allows the application to process by hardware time, instead of system time.

The main branch includes support for it, while the latest release does not.

Hi Takashi

I have a Focusrite Saffire PRO 24 which works perfectly with snd-firewire-improve.

I have built and installed libhinawa, no problem.

When I run the scripts, for example using "$ python qt5" or going up one level "$ ./samples/run.sh qt5" the script returns: No sound FireWire devices found.

How to fault find?

Cheers, Simon

Suggestion

I'm planning about moving maintainance under salsa.d.o. [1]
Salsa is a service instance of gitlab.
After migration, libhinawa debian package will be maintained at https://salsa.debian.org/debian/libhinawa.
[1] https://wiki.debian.org/Salsa

Comparison

Pros.

• upstream (github/libhinawa) need not to care how to maintain debian packages (Sure, you can maintain and coordinate package with )
• other DD also may be able to maintain libhinawa because DD can access to salsa.d.o/debian/libhinawa by default.

Cons.

• repository is split into two parts. mainline and debian specific one.
• need to create salsa.d.o account to contribute debian package. (if contributor is not DD)

Migration

upstream ( @takaswie ):

• just remove debian/*. It's all.

maintainer( @kenhys ):

• create repository for libhinawa debian package
• move it to salsa.d.o (ask DD to import that one)
• hack package under salsa.d.o, do regular maintainance task

Any thourght? @takaswie

See #5.

The sister project of libhinawa, libhinoko, provides Hinoko.CycleTimer structure for the content of CYCLE_TIMER register. The structure can be obsoleted by new Hinawa.CycleTime structure.

• takaswie/libhinoko#28

It requires libhinoko to have a new dependency to libhinawa. It means that libhinoko needs new stable version of libhinawa as soon.

Hi, I've just tried to build an rpm but with no luck. I have the following errors:
$
...
RPM build errors:
line 15: Possible unexpanded macro in: Requires: glib2(x86-64) >= %{glib2_version}
bogus date in %changelog: Thu Aug 24 2020 Takashi Sakamoto [email protected] - 2.2.0
bogus date in %changelog: Thu Aug 18 2020 Takashi Sakamoto [email protected] - 2.1.0
bogus date in %changelog: Thu May 20 2020 Takashi Sakamoto [email protected] - 2.0.0
bogus date in %changelog: Thu May 11 2020 Takashi Sakamoto [email protected] - 1.4.5
bogus date in %changelog: Thu Jan 20 2020 Takashi Sakamoto [email protected] - 1.4.4
bogus date in %changelog: Sun Mar 21 2019 Takashi Sakamoto [email protected] - 1.2.0
bogus date in %changelog: Sun Mar 5 2019 Takashi Sakamoto [email protected] - 1.1.2
bogus date in %changelog: Sun Feb 25 2019 Takashi Sakamoto [email protected] - 1.1.1
bogus date in %changelog: Tue Jun 20 2018 Takashi Sakamoto [email protected] - 1.0.0
bogus date in %changelog: Fri May 7 2017 Takashi Sakamoto [email protected] - 0.8.1-1
File not found: /home/admin/rpmbuild/BUILDROOT/libhinawa-2.2.0-1.el8.x86_64/usr/share/gtk-doc/html/hinawa/*
$

With 'File not found' seemingly fatal - nothing built.
Attached is the full output of the rpmbuild command:
libhinawa_rpm-build_fail.txt

Any fix/ work-around you can offer would be great. Thanks for your help.
Morgan.

This library is essentially for actual units on IEEE 1394 bus. Thus, it seems to be difficult to support autopkgtest for whole functionalities because it requires package maintainers to work with actual devices.

On the other hand, simple testing for linking is possible by instantiating or un-referring to object classes in the library.

Let's discuss about how to achieve it.

In IEEE 1394 bus, data is aligned to 4 bytes unit (quadlet) in packet payload. According to this specification, libhinawa requires to handle quadlet array for applications.

Currently, this quadlet array is represented by GArray. This is mainly due to GObject signal argument. It's 'requested' signal of FwResp object, and the other objects use the same representation.

But this may not be a better idea. GArray is a bit complicated type of GLib. If possible, they're represented by 'guint32 *' and length argument.

In meson build community, wrapDB is provided. It requires wrap file to describe dependency of software.

• https://mesonbuild.com/Wrap-dependency-system-manual.html

Libhinawa version 3.0.0 should support it, since libhinoko now depends on it.

• takaswie/libhinoko#26

At present, HinawaSndUnit has some methods for transaction, however this has an issue of mutual exclusives.

In this issue, below methods becomes to be deprecated. Users and developers should use HinawaFwReq object instead.

• hinawa_snd_unit_read_transact()
• hinawa_snd_unit_write_transact()
• hinawa_snd_unit_lock_transact()

Meson is a build system recently developed for better velocity of build processing.
http://mesonbuild.com/

I prepare for topic/meson-build branch and compare time to build for two cases.

With GNU autotools:

$ cat autotools.sh
#!/bin/bash

cd /tmp
git clone ~/git/libhinawa
cd libhinawa
./autogen.sh
./configure --enable-gtk-doc --prefix=/tmp/test
make -j10
make install

With meson:

$ cat meson.sh
#!/bin/bash

cd /tmp
git clone ~/git/libhinawa
cd libhinawa
meson -Dgtk_doc=true --prefix=/tmp/test . build
cd build
ninja
ninja install

As a result:

$ time ./autotools.sh
...
real	0m11.922s
user	0m12.955s
sys	0m1.294s

$ time ./meson.sh
...
real	0m2.035s
user	0m2.447s
sys	0m0.402s

Oh, fast.

lintian recommends to write down enough information for this package.
(This is not W: warning, but is is better to provide more information about this package)

N: 
N:    The extended description (the lines after the first line of the
N:    "Description:" field) is only one or two lines long. The extended
N:    description should provide a user with enough information to decide
N:    whether they want to install this package, what it contains, and how it
N:    compares to similar packages. One or two lines is normally not enough to
N:    do this.
N:    
N:    Refer to Debian Developer's Reference section 6.2.1 (General guidelines
N:    for package descriptions) and Debian Developer's Reference section 6.2.3
N:    (The long description) for details.
N:    
N:    Severity: minor, Certainty: possible
N:    
N:    Check: description, Type: binary, udeb
N: 

At present, most objects in this library utilize GArray to handle requests from caller with 32bit data. However, this brings some disadvantages. Especially, in any transactions on IEEE 1394 bus, originator can requests the transactions in byte unit. Current design of HinawaFwReq is not good for this type of requests.

In this issue, for HinawaFw* objects, use GByteArray for the data and change library interface. This corresponds to loss of backward compatibility, thus I create new release with updated major version.

@danielmellado encountered in the issue below:
takaswie/linux-firewire-dkms#28 (comment)

In the above issue, below command line is used to build:

$ meson -Dgtk_doc=true . build

However, if building with gobject-introspection support, gir=true should be passed, like:

$ meson -Dgir=true . build

This is the lack of information in README. It should be updated for user friendliness.

The suffixes of method, sync and async, are related to asynchronous I/O in GLib convention. The method with async works with GLib.Task and GLib.Cancellation for asynchronous I/O API, and the method with sync is for blocking I/O API.

Current libhinawa implements Hinawa.FwReq.transaction_sync() and Hinawa.FwReq.transaction_async(), while they acts differently from the above convention. The former blocks running user process for blocking, and the act follows the above convention. But the latter expects that user application operates GLib.MainContext to dispatch any event, and it is not an application of GLib.Task and GLib.Cancellation.

They should be renamed until libhinawa 3.0 release.

HinawaFwResp handles data of 'struct fw_cdev_event_request2' from Linux sound subsystem when asynchronous transaction reaches at allocated address. The data includes several members, but handler for 'requested' GObject signal can receive the part of the data, not whole. It's better to implement another GObject signal to receive the whole members.

Although GQuark is used to propagate error information for each GObject-derived object, the symbols are not exported yet. This issue brings inconvenience for Rust bindings to implement glib::error::ErrorDomain for the GQuark. The glib::error::ErrorDomain trait requires domain function implementation to return GQuark itself, however it's not exported and unable to access.

In GNU Compiler Collection, CPP has include syntax for #include directive. In the syntax, a file with angle brackets is for system header file, and a file with double quotes is for local header file:
https://gcc.gnu.org/onlinedocs/cpp/Include-Syntax.html

In libhinawa, some public headers for applications include the directive with double quotes. This is not better because it's intended to include system header file installed with the public headers.