Re: New packages for review

["David H. Gutteridge" <david%gutteridge.ca@localhost>]

On Mon, 2020-02-10 at 07:10 +0000, voidpin wrote:
> > Here are the results and fixes from another pass at building the
> > lxqt
> > meta package. (I'm drafting this message in featherpad, BTW.)
> Awesome, thanks for taking the time! I really like the balance between
> simplicity and features in featherpad, really nice editor.
> 
> > Failed to build    muparser-2.2.6.1
> > Fails to build when PKG_DEVELOPER=yes. This is a trivial issue.
> Yes and no. Your suggestion would fix this build but, muparser needs
> much
> heavier patching. I've e-mailed the maintainer about a month ago. I
> don't really
> have the hardware to fully test muparser, better to build lxqt-runner
> with
> math/muparser from the main branch for now.

Ah, okay. I'd assumed the newer version in wip was a hard dependency.

> > 336:[170/181] Failed to build    lximage-qt-0.14.1
> Fixed!
> 
> > 340:[172/181] Failed to build    pcmanfm-qt-0.14.1
> Fixed!
> 
> > 350:[177/181] Failed to build    lxqt-powermanagement-0.14.1
> Fixed! Sorry, this was a left-over from the previous build that
> slipped through.
> 
> > 356:[180/181] Failed to build    obconf-qt-0.14.1
> Fixed! Suck, all these translations... I thought I had catch them!
> 
> > 358:[181/181] Failed to build    lxqt-config-0.14.1
> Fixed! Thanks for this.
> 
> > I think LXQt needs more polish in its packaging to be on par with
> > the stock
> > installation experience of MATE, Xfce, LXDE, and others.
> > As-is, it doesn't present an actual desktop environment an end user
> > would
> > expect by default.
> This is a difficult one again and, I would say an upstream issue
> really.
> Prior to NetBSD, I was (still am) using Void Linux on top of musl-libC 
> (not
> GlibC). A philosophy (Void claims no philosophy) that I've learned to
> really
> appreciate was, do not impose anything on the end user. Although, I
> have to
> agree with your opinion, this is how LXQt is provided by upstream.
> Polishing
> the experience would require installing/creating directories/copying
> files
> into the users home directory. Personally, I'm against this but if you
> really
> find this necessary maybe it could be considered. Although, I think we
> should
> gather more opinions here on tech-pkg or pkgsrc-users mailing lists.

Oh, I'm not advocating for installing anything to a user's home
directory as a pkgsrc action. What I mean is, we're not necessarily
fulfilling LXQt's expectations of default configuration, and that's why
this disparity is occurring. Many upstream projects need to have their
default configurations adjusted, since they often think "all the world's
(mainstream) Linux". For example, LXQt thinks it should search for its
window manager in /usr/bin, not in ${PREFIX}/bin.

Have a look at x11/lxsession/Makefile, and you'll see an example of what
I mean. It needed to be adjusted to match locations defined by pkgsrc. I
expect LXQt will be similar, though I haven't had time to look into it.

> One question that I still have, though. In lxqt-panel, how many more
> OS
> exceptions should be added? Currently, I have NetBSD and OpenBSD. I
> know
> FreeBSD has their own code already inside LXQt upstream. DragonFly
> DPorts
> is pulling from FreeBSD ports and (not sure) is probably covered.

That's complicated... I'd say focus on NetBSD for now, since pkgsrc is
the only packaging source for the OS. Some of the other DEs in pkgsrc
have been focused on NetBSD. (One could say that's not ideal, but I
would also say it's not fair/realistic to expect one person to support
multiple OSes for software as complex as DEs, web browsers, etc.)

> Thank you for your time.
> If you can please try another build and check if there are issues
> still.

Sure, I can run another bulk build.

Thanks,

Dave