Re: Updating devel/tbb - Introducing devel/onetbb
On 10/1/21 4:29 am, Ganael Laplanche wrote: > 1) Move devel/tbb to a dedicated subdir and install devel/onetbb to its > default location. Here, we just anticipate what is written above. As you say, > as having devel/onetbb-only is the target, that would be the best solution > *BUT* it has the major disadvantage of having to patch all the current > dependent ports. This is error-prone and will require extra work I won't have > time to do. As I already wrote, I would prefer each porter to patch each port > himself (because he is the one who knows his port better that anyone). That's > why I suggested the second option. You don't have to do it all yourself, you create the bug reports to change tbb and to create onetbb, one report can depend on the other so they get committed together. My experience is being told to submit one report for each port, not one patch to change multiple ports. Then you create a report to say blender fails to build with your new port and add the report number to the Blocks list in your report. That leaves me to submit a patch to update blender to work with your change before your update can be committed. I would then add reports to update other dependencies that block my update. At most you submit 20 reports to say xx/yy port needs updating. There is devel/pybugz and ports-mgmt/freebsd-bugzilla-cli that could automate that but I haven't used them so can't recommend either. Then all the depends and blocks get updated together or some ports can get marked as broken if they fail to update in a suitable time. -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
please update devel/android-tools-adb to 30.0.x
I've updated my nexus5 to crDroid 7.2 (android 11). After that, I couldn't connect via adb. Please update devel/android-tools-adb to 30.0.x. P.S. I can connect via adb 30.0.5 on ubuntu. -- Masachika ISHIZUKA ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
can't build poudriere i386 arch: net/gitup
Hello, I'm trying to test a port in a different arch: doas poudriere bulk -j 114i386 -p ports net/gitup awk: can't open file /usr/local/poudriere/jails/114i386/usr/include/sys/param.h Could anyone please try latest gitup commit for me? https://github.com/johnmehr/gitup/issues/30 ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Updating devel/tbb - Introducing devel/onetbb
On Saturday, January 9, 2021 9:49:24 AM CET Shane Ambler wrote: Hello Shane, Thanks for your reply. > > - leave devel/tbb in place and introduce a new port: devel/onetbb > > While I would generally support moving the old libs to a new portname, > the fact that the project has renamed itself makes this acceptable. Yes, this is the idea. > The expected result is to have onetbb as the only option in the future, > you should leave the new port to use a standard install and only if > there is a need for it, alter the old port to co-install, you could get > lucky and not have anyone that wants both versions installed. I first thought about that too, but once several ports have started to use devel/onetbb, we could be in a situation where we have to relocate devel/tbb in a hurry (to avoid the CONFLICTS) because important ports still depending on devel/tbb cannot install anymore. I would like to avoid breaking important dependent ports that way as it can be anticipated. I don't know each failing port, but for example I have the following deps on my desktop machine (default options) : tbb <- suitesparse <- eigen <- movit <- mlt <- kdenlive <- kdemultimedia so anyone wanting to install a port using the new devel/onetbb will be unable to install kdemultimedia and that's a no-go for me. What I mean here is that just leaving devel/tbb and devel/onetbb in place and hoping noone will be facing a CONFLICT seems unrealistic. So that leaves only two possibilities : 1) Move devel/tbb to a dedicated subdir and install devel/onetbb to its default location. Here, we just anticipate what is written above. As you say, as having devel/onetbb-only is the target, that would be the best solution *BUT* it has the major disadvantage of having to patch all the current dependent ports. This is error-prone and will require extra work I won't have time to do. As I already wrote, I would prefer each porter to patch each port himself (because he is the one who knows his port better that anyone). That's why I suggested the second option. 2) The second option is to do quite the opposite : as everything is working fine now, don't touch anything and just introduce devel/onetbb in a way that it does not CONFLICT with current devel/tbb (i.e. in a dedicated subdir). It has several benefits : first, we don't break anything, then we leave each porter time to move their ports to devel/onetbb (we will not have to do that in a hurry) and finally, as each porter will have to move each port, if it is done by using a facility such as pkgconf, we gain a certain flexibility we don't have right now and that will ease next move (if there is one). The only disadvantage is that the library will not be located in the default paths anymore, but in a subdir. As we will have to patch dependent ports anyway to make them either detect the relocated devel/tbb (1st solution) or the new devel/onetbb (2nd solution), is that a problem ? Several ports already do that to be able to install several versions at the same time. That's why I still think it would be easier and less error-prone to introduce devel/onetbb to a specific location and go for solution 2). I would be pleased to receive other feedbacks. Maybe I am missing something here... ? > Use bugs.freebsd to manage the update, start with submitting onetbb, and > add conflicts with tbb. If dependent ports don't update and people want > both installed, submit changes to allow tbb to co-install and have > depends on bugs for each port that breaks so they get updated when the > tbb changes get committed. If we choose the second option, bugs.freebsd.org will probably be of less need, but it may be interesting to open a PR to follow ports migration anyway. I'll keep the idea in mind, thanks. > The blender port uses seven of the other ports (with options on), with > three others being slaves of one, so I expect that means a third of the > ports will need to be updated together, as I doubt they will work > together if they link to different tbb libs. > > > - add a PKGNAMESUFFIX to devel/tbb to 'freeze' its version and modify > > description to indicate the 'legacy' status of the port > > I don't see a need to make these changes to the existing port. Maybe > adding a note in the pkg-descr could make people aware of the new port. Yes, I will do that too. > > - [let maintainers migrate their ports to that new version] > > - at some time (?), mark devel/tbb as DEPRECATED with an EXPIRATION_DATE > > and do the same for remaining (non-updated) deps > > As long as the existing tbb library compiles, it can stay as it is. Once > maintaining the old port to build with new compilers/systems becomes a > chore, then mark tbb and deps as deprecated and give them six months to > update or be deleted. If all the deps get updated before then, the old > tbb port can just be deleted. > > If a port or two wants to stay with the old tbb, then let them maintain > the tbb port. Yes, why not.
FreeBSD ports you maintain which are out of date
Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/po...@freebsd.org.html Port| Current version | New version +-+ devel/pipestatus| 0.6.0 | 0.7.0 +-+ sysutils/google-compute-engine-oslogin | 20191018.00 | 20210108.00 +-+ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt Reported by:portscout! ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Updating devel/tbb - Introducing devel/onetbb
On 8/1/21 9:51 pm, Ganael Laplanche wrote: > - leave devel/tbb in place and introduce a new port: devel/onetbb While I would generally support moving the old libs to a new portname, the fact that the project has renamed itself makes this acceptable. > - design devel/onetbb to install files in dedicated subdirs so that it will > not CONFLICT with current devel/tbb (needed during migration phase) > - provide a pkgconf file that will be used by dependencies to locate those > files and include/link options easily The expected result is to have onetbb as the only option in the future, you should leave the new port to use a standard install and only if there is a need for it, alter the old port to co-install, you could get lucky and not have anyone that wants both versions installed. Use bugs.freebsd to manage the update, start with submitting onetbb, and add conflicts with tbb. If dependent ports don't update and people want both installed, submit changes to allow tbb to co-install and have depends on bugs for each port that breaks so they get updated when the tbb changes get committed. The blender port uses seven of the other ports (with options on), with three others being slaves of one, so I expect that means a third of the ports will need to be updated together, as I doubt they will work together if they link to different tbb libs. > - add a PKGNAMESUFFIX to devel/tbb to 'freeze' its version and modify > description to indicate the 'legacy' status of the port I don't see a need to make these changes to the existing port. Maybe adding a note in the pkg-descr could make people aware of the new port. > - [let maintainers migrate their ports to that new version] > - at some time (?), mark devel/tbb as DEPRECATED with an EXPIRATION_DATE and > do the same for remaining (non-updated) deps As long as the existing tbb library compiles, it can stay as it is. Once maintaining the old port to build with new compilers/systems becomes a chore, then mark tbb and deps as deprecated and give them six months to update or be deleted. If all the deps get updated before then, the old tbb port can just be deleted. If a port or two wants to stay with the old tbb, then let them maintain the tbb port. -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
