Re: [aur-general] [review-request] moolticute

[Quentin Bourgeois]

Hi,

Still about the moolticute packaging I am in a situation where
different tools (that will leave in different Arch package) will needs
access to the device. For that, I am considering moving the udev rules
in other package[0] and make every tools depend on the former[1].

I only see android-udev that perform the same thing, am I doing this
right ?

Thanks!

[0] https://git.bourgeois.eu/aur_mooltipass_udev.git/tree/PKGBUILD
[1] https://git.bourgeois.eu/aur_moolticute.git/tree/PKGBUILD#n12


signature.asc
Description: PGP signature

Re: [aur-general] [review-request] moolticute

[Quentin Bourgeois]

On 17-01-28 21:08:09, Eli Schwartz via aur-general wrote:
> On 01/28/2017 07:55 PM, Quentin Bourgeois wrote:
> > As the daemon is expected to talk with an USB device I included an
> > udev rules that should match it and allow logged user interaction.
> > In addition, the project does not include any systemd service
> > file. The daemon is expected to run for every user session so I use
> > systemd user instance. This service file is now very basic I will
> > first try to make it upstream, so every distribution could benefit
> > from this eventually. I guess that a lot are using systemd now.
>
> Yes, please do that. If upstream won't do so however, it is okay to
> bundle a service file with the PKGBUILD.
>
> Upstream should also, ideally, install a udev rule themselves. For some
> reason, their README explicitly tells Ubuntu and Arch users to create
> *different* udev rules by hand, using `echo ... | sudo tee`. Which is
> weird for several reasons.
>
Hi, sorry for the delay, I worked with upstream and both the systemd
service file and the udev rules will be provided in the next release
of the software. I also merge udev for Arch and Ubuntu as the rule
should work on every systemd based node.

> > While creating the systemd file I was wonderering how would be the
> > guideline in a case that an upstream systemd service file won't match
> > (for any reason) Arch Linux policy (let say applying it will break
> > the package functionality in Arch) would the good way to fix it in the
> > first would be to create in the PKGBUILD a systemd drop-ins?

Maybe a better way to turn my question would be: What if, an Arch
packager would like to improve in some way a systemd service provided
by upstream (for example by using one of the different isolation
mechanisms provided by systemd), but that improvement is rejected by
upstream for reason not application to Arch Linux.
But it could not make sense.

> I'm not sure what you even mean by this. How would a systemd unit break
> its own functionality, and if so, why wouldn't that be a cause for
> concern upstream?
> What Arch Linux policy would it violate anyway?
>
> > Regarding udev, after installing my rule I decided to force reloading
> > the rules files but not replaying event (only print a message to warn
> > the user). My view is that the later would only be needed for people
> > that already plugged the device before installing the package.
>
> Take a look at the (many) packages that own a file in
> /usr/lib/udev/rules.d/ and try to see how many of them include an
> install script explicitly reloading the rules. (Hint: None of them.)
> There is a reason for this, udev is already pretty smart.
>
> As for the message, surely that is rather obvious already? install
> scripts are meant for situations where simply installing the package
> isn't enough to actually make things work, or *vitally critical
> information is likely to elude the user* unless you bug them about it in
> a post-install message.
>
> Telling the user that an intuitive aspect of hardware device control
> applies here too, smells like over-mothering handholding to me.
>
Get it, I removed this part.

On 17-01-29 11:06:05, NicoHood wrote:
> On 01/29/2017 01:55 AM, Quentin Bourgeois wrote:
> > Hi,
> > 
> > I'm looking for uploading moolticute[0] into AUR but I still have some
> > doubt that my package has good taste or not. The project is in C++ and
> > use qt-5.
> 
> Hi,
> I also wanted to package moolticute for AUR but it was not ready at that
> time. I had not tried to package it again but still have it on my TODO
> list. It would be nice if you could contact me via tox/irc so we could
> possibly work together on this.
> 
> When moolticute gets popular enough I plan to move it to the official
> repository. We also have a good chance that upstream accepts our
> patches, as I've already worked with them and it shouldnt be that hard
> to apply some systemd patches for example.
> 
> So contact me in privat if you like to work together. I can also test
> with real hardware (Normal one and Mini Beta hardware).
> 
> Cheers,
> Nico
> 
Hi Nico, I will ping you on IRC for that. I will also package the
client and ssh-agent for AUR in the next week, so I will probably
asking new advice on Go package at that time.


signature.asc
Description: PGP signature

Re: [aur-general] [review-request] moolticute

[NicoHood]

On 01/29/2017 01:55 AM, Quentin Bourgeois wrote:
> Hi,
> 
> I'm looking for uploading moolticute[0] into AUR but I still have some
> doubt that my package has good taste or not. The project is in C++ and
> use qt-5.

Hi,
I also wanted to package moolticute for AUR but it was not ready at that
time. I had not tried to package it again but still have it on my TODO
list. It would be nice if you could contact me via tox/irc so we could
possibly work together on this.

When moolticute gets popular enough I plan to move it to the official
repository. We also have a good chance that upstream accepts our
patches, as I've already worked with them and it shouldnt be that hard
to apply some systemd patches for example.

So contact me in privat if you like to work together. I can also test
with real hardware (Normal one and Mini Beta hardware).

Cheers,
Nico



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] [review-request] moolticute

[Eli Schwartz via aur-general]

On 01/28/2017 07:55 PM, Quentin Bourgeois wrote:
> As the daemon is expected to talk with an USB device I included an
> udev rules that should match it and allow logged user interaction.
> In addition, the project does not include any systemd service
> file. The daemon is expected to run for every user session so I use
> systemd user instance. This service file is now very basic I will
> first try to make it upstream, so every distribution could benefit
> from this eventually. I guess that a lot are using systemd now.

Yes, please do that. If upstream won't do so however, it is okay to
bundle a service file with the PKGBUILD.

Upstream should also, ideally, install a udev rule themselves. For some
reason, their README explicitly tells Ubuntu and Arch users to create
*different* udev rules by hand, using `echo ... | sudo tee`. Which is
weird for several reasons.

> While creating the systemd file I was wonderering how would be the
> guideline in a case that an upstream systemd service file won't match
> (for any reason) Arch Linux policy (let say applying it will break
> the package functionality in Arch) would the good way to fix it in the
> first would be to create in the PKGBUILD a systemd drop-ins?

I'm not sure what you even mean by this. How would a systemd unit break
its own functionality, and if so, why wouldn't that be a cause for
concern upstream?
What Arch Linux policy would it violate anyway?

> Regarding udev, after installing my rule I decided to force reloading
> the rules files but not replaying event (only print a message to warn
> the user). My view is that the later would only be needed for people
> that already plugged the device before installing the package.

Take a look at the (many) packages that own a file in
/usr/lib/udev/rules.d/ and try to see how many of them include an
install script explicitly reloading the rules. (Hint: None of them.)
There is a reason for this, udev is already pretty smart.

As for the message, surely that is rather obvious already? install
scripts are meant for situations where simply installing the package
isn't enough to actually make things work, or *vitally critical
information is likely to elude the user* unless you bug them about it in
a post-install message.

Telling the user that an intuitive aspect of hardware device control
applies here too, smells like over-mothering handholding to me.

> Even with the i686 phase out, the tools seems to work great with this
> architecture, so I included it too.

Given that i686 isn't going to be dropped at all for months yet, and
even then stands a good chance of being kept alive as a second-tier,
officially-supported arch, I wouldn't be so hasty to drop it anyway. :)

> Finally, the release name[3] currently include "beta" (like v0.5.2-beta)
> does I have to put this into the pkgver or leave as 0.5.2?

Are they using the word "beta" to mean "we haven't reached the 1.0
milestone yet, and/or this project has no polish and may eat your
homework, #include " or "we are currently testing
something out that may not work, please check out our stable branch"?
That is how I would look at it.

-- 
Eli Schwartz



signature.asc
Description: OpenPGP digital signature

[aur-general] [review-request] moolticute

[Quentin Bourgeois]

Hi,

I'm looking for uploading moolticute[0] into AUR but I still have some
doubt that my package has good taste or not. The project is in C++ and
use qt-5.
I would like to upload a classical PKGBUILD[1] (with tag release) then
one that follow the git master branch[2].
As the daemon is expected to talk with an USB device I included an
udev rules that should match it and allow logged user interaction.
In addition, the project does not include any systemd service
file. The daemon is expected to run for every user session so I use
systemd user instance. This service file is now very basic I will
first try to make it upstream, so every distribution could benefit
from this eventually. I guess that a lot are using systemd now.

While creating the systemd file I was wonderering how would be the
guideline in a case that an upstream systemd service file won't match
(for any reason) Arch Linux policy (let say applying it will break
the package functionality in Arch) would the good way to fix it in the
first would be to create in the PKGBUILD a systemd drop-ins?

Regarding udev, after installing my rule I decided to force reloading
the rules files but not replaying event (only print a message to warn
the user). My view is that the later would only be needed for people
that already plugged the device before installing the package.

Even with the i686 phase out, the tools seems to work great with this
architecture, so I included it too.

Finally, the release name[3] currently include "beta" (like v0.5.2-beta)
does I have to put this into the pkgver or leave as 0.5.2?

If comments/directions I will be glad to improve my work.

Thanks !

[0] https://github.com/raoulh/moolticute
[1] 
https://git.bourgeois.eu/aur_moolticute.git/tree/PKGBUILD?id=85e4d6f29352a54d85c00f3dfd2c5f1fef052811
[2] 
https://git.bourgeois.eu/aur_moolticute_git.git/tree/PKGBUILD?id=140f3e3efceacf5ca24d2a77c04458a80d998c8a
[3] https://github.com/raoulh/moolticute/releases
# Maintainer: Quentin Bourgeois 

pkgname=moolticute
pkgver=0.5.2
pkgrel=1
pkgdesc="Easy companion for Mooltipass device"
arch=('x86_64' 'i686')
url="https://github.com/raoulh/${pkgname};
license=('GPL3')

depends=('libusb'
 'qt5-base'
 'qt5-websockets')

makedepends=('make')
checkdepends=()
optdepends=()
install="${pkgname}.install"

source=("${pkgname}-${pkgver}.tar.gz::${url}/archive/v${pkgver}-beta.tar.gz"
'69-mooltipass.rules'
'moolticute.service')
sha256sums=('a22d4078870da77affb67c7eae2d2cc426ec799a0928f494df32ab995431fe8a'
   'e8e8da3f29d27e34a9f41b23ba04b74dbf25bcc7d586e5b6d2ee72bade889503'
   '135d7dda3698872745bec79fa2ee7a964fa2fbc90f90d1d57e034bc0104ce13a')

build() {
cd "${pkgname}-${pkgver}-beta"

mkdir build
cd build/

qmake-qt5 ../Moolticute.pro \
  PREFIX=/usr   \
  QMAKE_CFLAGS_RELEASE="${CFLAGS}"  \
  QMAKE_CXXFLAGS_RELEASE="${CXXFLAGS}"

make
}

package() {
cd "${pkgname}-${pkgver}-beta/build/"

make INSTALL_ROOT="${pkgdir}/" install
install -Dm644 "${srcdir}/69-mooltipass.rules" \
"${pkgdir}/usr/lib/udev/rules.d/69-mooltipass.rules"
install -Dm644 "${srcdir}/moolticute.service" \
"${pkgdir}/usr/lib/systemd/user/moolticute.service"
}
# Maintainer: Quentin Bourgeois 

pkgname=moolticute-git
_pkgname="${pkgname%-git}"
pkgver=0.5.2.r0.g9486816
pkgrel=1
pkgdesc="Easy companion for Mooltipass device"
arch=('x86_64' 'i686')
url="https://github.com/raoulh/${_pkgname};
license=('GPL3')
provides=("${_pkgname}")
conflicts=("${_pkgname}")
depends=('libusb'
 'qt5-base'
 'qt5-websockets')

makedepends=('git'
 'make')
checkdepends=()
optdepends=()
install="${_pkgname}.install"

source=("git+${url}.git"
'69-mooltipass.rules'
'moolticute.service')
sha256sums=('SKIP'
'e8e8da3f29d27e34a9f41b23ba04b74dbf25bcc7d586e5b6d2ee72bade889503'
'135d7dda3698872745bec79fa2ee7a964fa2fbc90f90d1d57e034bc0104ce13a')

pkgver() {
cd "${srcdir}/${_pkgname}"
git describe --long --tags | sed 
's/beta.//;s/^v//;s/\([^-]*-g\)/r\1/;s/-/./g'
}

build() {
cd "${srcdir}/${_pkgname}"

mkdir build
cd build/

qmake-qt5 ../Moolticute.pro \
  PREFIX=/usr   \
  QMAKE_CFLAGS_RELEASE="${CFLAGS}"  \
  QMAKE_CXXFLAGS_RELEASE="${CXXFLAGS}"

make
}

package() {
cd "${srcdir}/${_pkgname}/build/"

make INSTALL_ROOT="${pkgdir}/" install
install -Dm644 "${srcdir}/69-mooltipass.rules" \
"${pkgdir}/usr/lib/udev/rules.d/69-mooltipass.rules"
install -Dm644 "${srcdir}/moolticute.service" \
"${pkgdir}/usr/lib/systemd/user/moolticute.service"
}