Re: Testing a port built with poudriere
bob prohaska wrote on 2021/05/27 11:14: > Is it possible to try out the lxqt package without altering the > existing ports installed using make in the ports tree? > I think it would be difficult to do it without modifying the host environment. You probably also need the x11-servers/xorg-nestserver package. The following command will launch the interactive shell of jail, which has everything you need for now. poudriere bulk -j main -i x11-wm/lxqt x11-servers/xorg-nestserver x11/xterm After this, you have to make nestserver connect to the host Xorg via ssh or something, but the explanation of that is tedious :) Regards.
Re: Testing a port built with poudriere
On 27/05/21 09:08, Tatsuki Makino wrote: bob prohaska wrote on 2021/05/27 11:14: Is it possible to try out the lxqt package without altering the existing ports installed using make in the ports tree? I think it would be difficult to do it without modifying the host environment. You probably also need the x11-servers/xorg-nestserver package. The following command will launch the interactive shell of jail, which has everything you need for now. poudriere bulk -j main -i x11-wm/lxqt x11-servers/xorg-nestserver x11/xterm After this, you have to make nestserver connect to the host Xorg via ssh or something, but the explanation of that is tedious :) I''d suggest, after building the package set with poudriere, to use some virtualization solution (bhive, virtualbox, or emulation like qemu if a different architecture is required (arm for example)) to test the packages without interfering with the host system installation. Vagrant can also be helpful in simplifying repetitive tasks with VMs. -- Guido Falsi
Node/npm-based ports in 2021 - Thoughts?
Hi folks, I came across a PR [1] for adding a new port www/code-server [2], a node/npm-based application. Over the years I have been avoiding npm-based ports since I believe it was not really supported and also discouraged [3], however, I think this particular application (along with an increasing number of system utilities) is valuable and is worth putting in the ports tree. I guess my wondering is: - For this particular port, is there a "more correct" way of doing this? I commented on the PR [1] but found that my domain knowledge is quite limited. - Is there (or will there be) any development on supporting nodejs/npm-based applications? Thanks! +cc yuri@ (for misc/netron, [4]), swills@ since I recalled that you worked on some ports using npm before, sorry for the spam in advance :) [1]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256144 [2]: https://github.com/cdr/code-server [3]: https://forums.freebsd.org/threads/node-js-based-ports-how-do-you-handle-the-npm-install.56659/ [4]: https://github.com/freebsd/freebsd-ports/blob/main/misc/netron/Makefile -- Guangyuan Yang y...@freebsd.org
Re: How to correctly reference WRKSRC of another port?
On Wed, May 26, 2021 at 12:46:20AM +0200, Philipp Ost wrote:
> Thanks everyone for your help and suggestions so far!
>
> On 5/25/21 4:16 PM, Mathieu Arnold wrote:
> > On Mon, May 24, 2021 at 08:16:47PM +0200, Philipp Ost wrote:
> [snip]>
> > There is no best way to achieve what you need. The probably easiest way
> > would be to follow what audio/pulseaudio-module-xrdp does, mainly:
> >
> > BUILD_DEPENDS= ${NONEXISTENT}:math/nauty:patch
> > NAUTY_WRKSRC= $$(${MAKE} -C ${PORTSDIR}/math/nauty -VWRKSRC)
> >
> > and then wherever you hardcoded the /usr/ports/... just put
> > ${NAUTY_WRKSRC}.
>
> Jan suggested essentially the same. ;-)
>
> > Note that the special BUILD_DEPENDS is required, otherwise, there is no
> > guarantee that the sources will actually be there. Also, the :patch at
> > the end is the target youu actually need the sources to be in, maybe it
> > should be :configure or :build.
>
> The :extract target did work fine, it's actually just the raw sources which
> are needed. In the meantime some gremlins have crept in and now nothing
> seems to work as it did yesterday... Now I can't get the nauty sources to
> extract properly, neither using :extract or :patch. NAUTY_WRKSRC is set
> correctly; right now I don't know what might be amiss. If I can't figure it
> out myself I fear I have to bug the list again.
If you only need the sources, it is probably better to simply add the
nauty distribution file to DISTFILES.
--
Mathieu Arnold
signature.asc
Description: PGP signature
Re: How to correctly reference WRKSRC of another port?
> On May 27, 2021, at 5:31 AM, Mathieu Arnold wrote:
>
> On Wed, May 26, 2021 at 12:46:20AM +0200, Philipp Ost wrote:
>> Thanks everyone for your help and suggestions so far!
>>
>> On 5/25/21 4:16 PM, Mathieu Arnold wrote:
>>> On Mon, May 24, 2021 at 08:16:47PM +0200, Philipp Ost wrote:
>> [snip]>
>>> There is no best way to achieve what you need. The probably easiest way
>>> would be to follow what audio/pulseaudio-module-xrdp does, mainly:
>>>
>>> BUILD_DEPENDS= ${NONEXISTENT}:math/nauty:patch
>>> NAUTY_WRKSRC= $$(${MAKE} -C ${PORTSDIR}/math/nauty -VWRKSRC)
>>>
>>> and then wherever you hardcoded the /usr/ports/... just put
>>> ${NAUTY_WRKSRC}.
>>
>> Jan suggested essentially the same. ;-)
>>
>>> Note that the special BUILD_DEPENDS is required, otherwise, there is no
>>> guarantee that the sources will actually be there. Also, the :patch at
>>> the end is the target youu actually need the sources to be in, maybe it
>>> should be :configure or :build.
This feels like the kind of thing that a "How Do I"...wiki would benefit from.
>>
>> The :extract target did work fine, it's actually just the raw sources which
>> are needed. In the meantime some gremlins have crept in and now nothing
>> seems to work as it did yesterday... Now I can't get the nauty sources to
>> extract properly, neither using :extract or :patch. NAUTY_WRKSRC is set
>> correctly; right now I don't know what might be amiss. If I can't figure it
>> out myself I fear I have to bug the list again.
>
> If you only need the sources, it is probably better to simply add the
> nauty distribution file to DISTFILES.
>
> --
> Mathieu Arnold
An apology about my commits
Hi freebsd-ports@, ports-committers@, I hope all is well with you. You may know I have prematurely made Ports commits without review, namely 507359c509389602b4060b2c5e203c99911c3578 and 0bc7478682b2d7c9393f2dd095d99072070a2f65. I'm really sorry if I pushed these commits without approval. I feel extremely guilty for making these commits without approval, and almost felt I will lose my commit bit. I even thought at times that I will have to switch my PCs/servers to Windows or Linux if all goes wrong since I will feel shame for even **using** FreeBSD [1]. Next time, I will try not to bypass review, especially for big commits that touch major packages like devel/glib20. However, to unbreak the fetching for GNOME Ports that have been updated to 40.x, we will need to make one change to Mk/bsd.sites.mk. This patch is in https://reviews.freebsd.org/D30514 . This may need portmgr approval, but I won't commit it without approval. Happy hacking! -Neel Chauhan (nc@) Footnotes: [1] - For reference, I work at Microsoft and use Windows at work, but used FreeBSD almost exclusively at home since 2012, back when I was only 15 (I'm 24 now), and more-or-less the only server OS I have run my home servers on since I set that up in 2013.
Re: An apology about my commits
On 28/05/2021 1:19 pm, Neel Chauhan wrote: Hi freebsd-ports@, ports-committers@, I hope all is well with you. You may know I have prematurely made Ports commits without review, namely 507359c509389602b4060b2c5e203c99911c3578 and 0bc7478682b2d7c9393f2dd095d99072070a2f65. I'm really sorry if I pushed these commits without approval. I feel extremely guilty for making these commits without approval, and almost felt I will lose my commit bit. I even thought at times that I will have to switch my PCs/servers to Windows or Linux if all goes wrong since I will feel shame for even **using** FreeBSD [1]. Next time, I will try not to bypass review, especially for big commits that touch major packages like devel/glib20. However, to unbreak the fetching for GNOME Ports that have been updated to 40.x, we will need to make one change to Mk/bsd.sites.mk. This patch is in https://reviews.freebsd.org/D30514 . This may need portmgr approval, but I won't commit it without approval. Happy hacking! -Neel Chauhan (nc@) Footnotes: [1] - For reference, I work at Microsoft and use Windows at work, but used FreeBSD almost exclusively at home since 2012, back when I was only 15 (I'm 24 now), and more-or-less the only server OS I have run my home servers on since I set that up in 2013. It's your thoughts and care that count Neel, don't feel guilty. The responses you received could have been a bit more 'matter of fact'. What was *actually* important about the replies was 'we should be QA'ing everything and getting more than one persons eyes on things'. Note (for everyone), some of the biggest impacts are caused by the smallest commits. The idea of a 'trivial update' needs to be related to the dustbin, and we're still hearing it often.
Re: An apology about my commits
On 28/05/2021 1:25 pm, Kubilay Kocak wrote: On 28/05/2021 1:19 pm, Neel Chauhan wrote: Hi freebsd-ports@, ports-committers@, I hope all is well with you. You may know I have prematurely made Ports commits without review, namely 507359c509389602b4060b2c5e203c99911c3578 and 0bc7478682b2d7c9393f2dd095d99072070a2f65. I'm really sorry if I pushed these commits without approval. I feel extremely guilty for making these commits without approval, and almost felt I will lose my commit bit. I even thought at times that I will have to switch my PCs/servers to Windows or Linux if all goes wrong since I will feel shame for even **using** FreeBSD [1]. Next time, I will try not to bypass review, especially for big commits that touch major packages like devel/glib20. However, to unbreak the fetching for GNOME Ports that have been updated to 40.x, we will need to make one change to Mk/bsd.sites.mk. This patch is in https://reviews.freebsd.org/D30514 . This may need portmgr approval, but I won't commit it without approval. Happy hacking! -Neel Chauhan (nc@) Footnotes: [1] - For reference, I work at Microsoft and use Windows at work, but used FreeBSD almost exclusively at home since 2012, back when I was only 15 (I'm 24 now), and more-or-less the only server OS I have run my home servers on since I set that up in 2013. It's your thoughts and care that count Neel, don't feel guilty. The responses you received could have been a bit more 'matter of fact'. What was *actually* important about the replies was 'we should be QA'ing everything and getting more than one persons eyes on things'. Note (for everyone), some of the biggest impacts are caused by the smallest commits. The idea of a 'trivial update' needs to be related to the dustbin, and we're still hearing it often. ugh, relegated*
Re: An apology about my commits
It's your thoughts and care that count Neel, don't feel guilty. Thanks! The responses you received could have been a bit more 'matter of fact'. What was *actually* important about the replies was 'we should be QA'ing everything and getting more than one persons eyes on things'. True, especially for big packages like GNOME, KDE, Mozilla, Xorg, or LibreOffice. Sometimes, I get trigger-happy. But I really shouldn't, well unless it's a hobby project on GitHub. Note (for everyone), some of the biggest impacts are caused by the smallest commits. The idea of a 'trivial update' needs to be related to the dustbin, and we're still hearing it often. +1 I've had "trivial updates" that broke things, both in and outside FreeBSD. I've had code broken at my $DAYJOB, and that a Microsoft SaaS product (not a household name product like Windows or Word, but still). I was a major Tor contributor from 2017-2020 and had bad patches that broke things or add bugs get in, and that with Tor being very security-focused. And hey, it's not like I'm pulling a University of Minnesota "research project" where the goal is to intentionally add bugs to the Linux kernel. -Neel
