[aur-general] TU Application: David Runge

[David Runge]

On 2017-10-25 00:08:31 (-0400), Eli Schwartz wrote:
> Well, yeah. It's more clear what you're doing.
> 
> FWIW, I typically use a source url like this:
> 
> _file=742770
> source=("${_pkgname}-${pkgver}.xpi::https://addons.mozilla.org/firefox/downloads/file/${_file}/")
Hmm, this doesn't seem to provide a valid download url for tab tree.
In any case, I changed it to a more sane/readable file name already.

> It's a pity that Mozilla doesn't provide a stable API to get an
> extension by name and version, and the only way is with a file instead.
Yes.

> >> mantisbt:
> >> - this incredibly gross install script messes around with unpackaged
> >>   files, please don't do this
> > Okay. What would be a good alternative though?
> > Using the application during upgrade might potentially break the
> > database. However, the mantis_offline.php file prevents users from
> > interacting with the application.
> > I know that hooks such as the one introduced for nextcloud quite
> > recently (for a while) won't work either.
> 
> Hmm, actually I'm not sure what the solution to that is. Has upstream
> ever considered doing something more sane like autotriggering offline
> mode when the version in the *database* indicates it is out of date? :D
I think that would indeed be a good feature request. ;-)

> But the major thing that I didn't like was the rm -rf in the
> post_remove. I cannot think of a good reason to be doing that, unless
> the application stores user data there, and in that case I don't think
> you should be deleting user data. The user can clean up their leftover
> data by hand once they are sure they don't need it anymore, which is
> safer than causing it to accidentally get deleted when they didn't
> intend to do so.
That's correct and I removed it (also: version bump).
I should have probably thought about the install script more, when
mantisbt was dropped from community [1].
Maybe it was introduced to take care of dead copies of the
mantis_offline.php file... but also that doesn't make much sense.

> > Also: Debugging seems to be activated in the main repository as well. oO
> 
> I have no good explanation for this, but speps isn't really around much
> to ask him anymore...
> 
> Originally added in pd 0.46.7-1 back in 2015 and never changed.
> 
> This is why it would be nice to have debugging repos, of course. Also
> special --enable-debug flags are generally not needed when using
> options=('debug') will enable debug flags in CFLAGS anyway, so if for
> some reason debug was enabled at all, I'd expect to see that happen in
> the options array.
It would be indeed a very nice thing to have. Often, when running into
issues with more complex pieces of software, such as DAWs, it can be
very helpful (if you can actually reproduce your issue).

> >> - patching should also go in prepare(), and come before autogen on
> >>   principle
> > Sadly I have to patch configure. Upstream is veeeeeeeeeeeery slow on
> > merging pull requests, so the switch to qt5, that would make this all go
> > away, is still not upon us :(
> > Moved.
> 
> Well, no. You "need" to patch configure.ac instead. :D
Whoops. That's correct.
Guess I jumped a step, as I rebuilt it very frequently for my thesis.
What would be the thing to do for the non-git version of the package
though, as configure is already present? I could run autoreconf again I
guess.

> >> supercollider-git:
> git describe HEAD is the same as git describe, the HEAD there just seems
> a bit out of place (and introduces a very minor degree of complexity to
> analyze). As per git-describe(1), "Commit-ish object names to describe.
> Defaults to HEAD if omitted."
Fixed.

> As for their tagging problems, seems to me there's a blatantly simple
> solution. :D Just use annotated tags for all versioned releases, and use
> lightweight tags for whatever inaccurate tag-which-should-be-a-branch
> they want....
> 
> But if you want real fun, see the qbittorrent-git PKGBUILD which I
> co-maintain.
> It appears to be policy to maintain a master branch for development and
> a vX_X_X branch for cherry-picking release commits just in time for
> tagging a release. Or something.
"Not listening..." :>

> >> - why some big complicated switch for configuring based on the CARCH,
> >>   why don't you just use the $CARCH variable you already have available,
> >>   and if you actually have to do different things depending on the
> >>   CARCH, then you can make this a lot easier to read by including extra
> >>   options in a bash array for safe tokenization.
> > Sounds interesting. Will rework this, as soon as I have my Pis up and
> > running again.
> > Note however, that some hacks are necessary for supercollider to
> > function on a headless system (which embedded systems often are).
> 
> Hacks are fine, making the application of those hacks more readable is
> even better. ;)
True. Hope I can (finally) unpack my ARMs this week again.

> Happy to help, this is a bit of a hobby of mine. :) Thanks for the quick
> response, seeing how TU applicants respond to such critiques is I am
> pretty sure nearly as important as getting things right the first time. ;)
Well, I'm always happy to improve things. Especially, if it helps
maintainability.

> Good luck.
Thanks!


[1] https://aur.archlinux.org/cgit/aur.git/commit/?h=mantisbt&id=fd9c1e837b6ccf980b2d760684614b51f76d5a8f


-- 
https://sleepmap.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.archlinux.org/pipermail/aur-general/attachments/20171030/ef4c299b/attachment.asc>