Re: No port should need root for make fetch
Le 14/12/2016 à 06:17, Peter Jeremy a écrit : > On 2016-Dec-13 21:32:36 +0100, "Julian H. Stacey" wrote: >> IMO No port should need root for >> cd /usr/ports; make -i fetch > In a stock FreeBSD install, all ports require root to both fetch and build. > You have customised your system in a non-standard way so you are getting > non-standard behaviour which doesn't match you expectations. That is plain not true. The numbers of ports that need root to fetch and build can be counted on one hand, and need to be fixed. We have QAT builds that check it: http://package19.nyi.freebsd.org/build.html?mastername=103i386-default-build-as-user&build=428533 poudriere-devel defaults as doing everything as a non root user (default nobody), except executing all the -depends target, as they need to install stuff in LOCALBASE. -- Mathieu Arnold signature.asc Description: OpenPGP digital signature
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/libthai | 0.1.25 | 0.1.26 +-+ math/giacxcas | 1.2.2-57| 1.2.2-105 +-+ net/ipsumdump | 1.85| 1.86 +-+ 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 Thanks. ___ 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"
Make index fails with no entry for /usr/ports/audio/linux-c7-mikmod
curlew:/root# freebsd-version -ku 11.0-RELEASE-p2 11.0-RELEASE-p5 curlew:/root# make -C /usr/ports index Generating INDEX-11 - please wait..--- describe.accessibility --- --- describe.arabic --- --- describe.archivers --- [snip] --- describe.x11-toolkits --- --- describe.x11-wm --- make_index: /usr/ports/games/linux-uplink-demo: no entry for /usr/ports/audio/linux-c7-mikmod curlew:/root# ls -l /usr/ports/audio/linux-c7-mikmod ls: /usr/ports/audio/linux-c7-mikmod: No such file or directory https://www.freebsd.org/cgi/ports.cgi?query=linux-c7-mikmod&stype=all reports nothing found so what's causing make index to try to index it? -- Mike Clarke ___ 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: (In)Stability of the Quarterly Branch
2016-11-16 13:17 GMT+01:00 Vlad K. : > The quarterly branch (Q) is intended to provide a set of "stable" packages > that in the lifetime of such a branch, receive only bug and security fixes. > That is the theory and intent behind the branch. In practice, however: > > 1. The Q branch is cut off at predetermined dates (ie. not when it's stable > and ready), and it is cut off from HEAD, thus including the state of ports > at that moment. This breaks the promise of stability and guarantees that > every 3 months there will be uncertainty as to whether the fresh new > versions are working or not. There is no such thing as a "Pre-Quarterly > repo" which would receive all updates for the NEXT Q branch-off, and which > would freeze and stabilize for some time before branch-off. And even if it > did, 3 months would be too short. > > It is effectively not much different from tracking HEAD and doing updates > only every three months, with the added benefit that SOME security updates > will come down sooner. But: > > 2. Unfortunately not all "security or bug-only fixes" are MFH'd, and as a > bugzilla triager I've had the opportunity to observe this in practice. It > can be as simple as accepting a minor upstream version bump, or as complex > as requiring cherry-picking and backporting code if upstream mixes security, > bug fixes with new features. It is none-the-less a manual work requiring > ports-secteam to review and accept the patches. It is not clear who is > supposed to do cherry-picked backporting if the patches to HEAD cannot be > MFH'd as they are. It is also additional burden to the ports-secTEAM which > at the moment is, effectively, one person. > > As it is obvious that the promise of a stable repo in its current form > requires manpower and manual work which we do not have, my proposal is to > abandon the promise of "security/bugfix" only changes and adopt the approach > not unlike Gentoo's, in which a "STABLE" repository receives ALL the updates > from HEAD, but only after certain criteria has been met, like minimal age of > changes, no open issues, a certain battery of regression/integration/unit > tests is performed, etc... > The problem is that there are no tests in FreeBSD ports. All source based systems I've tested: pkgsrc, FreeBSD ports, OpenBSD, Gentoo; FreeBSD is the one that have the most instability. Not to mention committers that commit without testing the port, just look at www/redmine to get your point of view on that issue. On the other hand, your idea is indeed good and could be a good start. Quaterly branches change too quickly. That's simple: each time I install a new port, I'm behind 2 or 3 quarters the last one. So I usually update all before installing the new one. What I want: a ports tree that matches the FreeBSD version like OpenBSD. You have FreeBSD 11.0? You get a ports tree for that version specifically. No major update, no breaking changes. Just bug fixes. That will also simplify a lot FreeBSD ports by not having thousands of conditional checking the FreeBSD version. Waiting for more stability, I really encourage people to use poudriere to build packages to avoid breaking a system at each upgrade. Regards, -- Demelier David ___ 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: (In)Stability of the Quarterly Branch
On 15.12.2016 14:16, David Demelier wrote: 2016-11-16 13:17 GMT+01:00 Vlad K. : The quarterly branch (Q) is intended to provide a set of "stable" packages that in the lifetime of such a branch, receive only bug and security fixes. That is the theory and intent behind the branch. In practice, however: 1. The Q branch is cut off at predetermined dates (ie. not when it's stable and ready), and it is cut off from HEAD, thus including the state of ports at that moment. This breaks the promise of stability and guarantees that every 3 months there will be uncertainty as to whether the fresh new versions are working or not. There is no such thing as a "Pre-Quarterly repo" which would receive all updates for the NEXT Q branch-off, and which would freeze and stabilize for some time before branch-off. And even if it did, 3 months would be too short. It is effectively not much different from tracking HEAD and doing updates only every three months, with the added benefit that SOME security updates will come down sooner. But: 2. Unfortunately not all "security or bug-only fixes" are MFH'd, and as a bugzilla triager I've had the opportunity to observe this in practice. It can be as simple as accepting a minor upstream version bump, or as complex as requiring cherry-picking and backporting code if upstream mixes security, bug fixes with new features. It is none-the-less a manual work requiring ports-secteam to review and accept the patches. It is not clear who is supposed to do cherry-picked backporting if the patches to HEAD cannot be MFH'd as they are. It is also additional burden to the ports-secTEAM which at the moment is, effectively, one person. As it is obvious that the promise of a stable repo in its current form requires manpower and manual work which we do not have, my proposal is to abandon the promise of "security/bugfix" only changes and adopt the approach not unlike Gentoo's, in which a "STABLE" repository receives ALL the updates from HEAD, but only after certain criteria has been met, like minimal age of changes, no open issues, a certain battery of regression/integration/unit tests is performed, etc... The problem is that there are no tests in FreeBSD ports. All source based systems I've tested: pkgsrc, FreeBSD ports, OpenBSD, Gentoo; FreeBSD is the one that have the most instability. Not to mention committers that commit without testing the port, just look at www/redmine to get your point of view on that issue. www/redmine is a special case like for example GitLab. This are ports based on rubygems and the ports-tree has a hard time to replicate the gems. When one port need an update for a specific gem another can break. Other systems avoid the problem by ignoring it. You need to install and maintain all gems by yourself. This includes updates, security checks and of course installation of dependencies. On the other hand, your idea is indeed good and could be a good start. Quaterly branches change too quickly. That's simple: each time I install a new port, I'm behind 2 or 3 quarters the last one. So I usually update all before installing the new one. What I want: a ports tree that matches the FreeBSD version like OpenBSD. You have FreeBSD 11.0? You get a ports tree for that version specifically. No major update, no breaking changes. Just bug fixes. That will also simplify a lot FreeBSD ports by not having thousands of conditional checking the FreeBSD version. That what i really, really, really NOT want. I have regular problems with our admins because of that. You want a specific version of an software? No problem: just install a specific version of your operation system. Need two of them, but they are not in this bundle? To bad, than you need a new server. This is an daily-base scenario i really don't want to port to FreeBSD. Yes, there are problems and tests are very helpful. But you need to check why something is broken. Often the upstream is broken, not the port. In the case of redmine the ports-tree lacks the pessimistic operator which can catch many of the breaks in the last. It is one idea to teach the ports-tree how this work. Also there is an ongoing effort in increasing the tests. Every help is appreciated! Waiting for more stability, I really encourage people to use poudriere to build packages to avoid breaking a system at each upgrade. This is a good idea. But does not help everytime. Many rubygem based ports build just fine, but fail afterwards. Greetings, Torsten ___ 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: (In)Stability of the Quarterly Branch
Torsten Zuehlsdorff wrote on 2016/12/15 14:43: The problem is that there are no tests in FreeBSD ports. All source based systems I've tested: pkgsrc, FreeBSD ports, OpenBSD, Gentoo; FreeBSD is the one that have the most instability. Not to mention committers that commit without testing the port, just look at www/redmine to get your point of view on that issue. www/redmine is a special case like for example GitLab. This are ports based on rubygems and the ports-tree has a hard time to replicate the gems. When one port need an update for a specific gem another can break. Other systems avoid the problem by ignoring it. You need to install and maintain all gems by yourself. This includes updates, security checks and of course installation of dependencies. First - I really appreciate your work on ports! And now Redmine - I think I was bitten by every Redmine failure after upgrade :) I wonder if the solution for ports like Redmine can be some kind of isolation. Python have virtualenv, AFAIK Ruby has something like this too. Will it be possible to connect ports (packages) with some type of "environment" defined just for "this package"? Miroslav Lachmanh ___ 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: The ports collection has some serious issues
On Thu, 8 Dec 2016, Daniil Berendeev wrote: 5) svn repository. I don't want to spark a holy war and I don't belong to those type of people who are always obsessed that something isn't done in their way. But guys, svn is not a good tool for ports. Just for one reason, actually (as for me, I could tolerate anything else, but not this one) -- size. The size of repository is 20G+ and growing. I don't want to pull 20G+ in /usr/ports just because I need to use ports. It's just sick. The repository is so big because, as all ya know, svn is expensive in branch operations. Since you've began to do those 2xxxQx branches the size of the repository began to grow rapidly. It's inefficient and uncomfortable. For such a work something like git or mercurial should be used, they'd fit in 3-4G. Here, it doesn't look like that. Don't forget that /usr/ports/distfiles accumulates old versions and must be manually cleaned out from time to time. portmaster has a couple of options to remove distfiles that are not needed. % du -hd0 /usr/ports 8.1G/usr/ports % du -hd0 /usr/ports/distfiles 6.5G/usr/ports/distfiles After copying that to /tmp and deleting distfiles entirely: % du -hd0 /tmp/usr/ports 1.4G/tmp/usr/ports Deleting /usr/ports/distfiles entirely is something I avoid because it seems that just when an urgent rebuild is needed, a distfile will be unfetchable. The portmaster options can keep distfiles only for currently installed ports, or current distfiles for any port, whether installed or not. ___ 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: The ports collection has some serious issues
On Thu, 8 Dec 2016, Matt Smith wrote: On Dec 08 05:16, Daniil Berendeev wrote: Although portmaster is not releated to the FreeBSD project and is an outside tool, there aren't any alternatives from the project itself. So use it or die. Not a nice situation. People have been trying to get portmaster deprecated and removed from the handbook but have met with resistance. Well, yes. Because it works, has no dependencies, and there is no equivalent replacement. Except maybe portupgrade, which has legacy problems like poor default options. The recommended replacements are ports-mgmt/synth and ports-mgmt/poudriere. These build an entire package repository that the pkg tool can use but they do so in clean chrooted environments, and rebuild everything that's required to keep a consistent ABI. Synth is more designed for a single live system like a desktop or a single server, whereas poudriere is what the freebsd package build clusters use and is more designed for that type of usage. Worth taking a look. These are package builders. Technically preferable, given adequate disk space and memory, but not equivalent to portmaster. It's a shame the handbook hasn't been updated to give this information. Which information, in particular? A section on Poudriere was submitted, and I spent a fair amount of time editing it and getting it in there. As far as Synth or other information, I'm not aware of any pending Handbook or other documentation submissions. ___ 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"
munin-master won't build: no 'module_name' or MANIFEST file
Hi, I'm trying to rebuild munin-master but keep running into this: cd master && /usr/local/bin/perl Build.PL No 'module_name' was provided and it could not be inferred from other properties. This will prevent a packlist from being written for this file. Please set either 'module_name' or 'dist_version_from' in Build.PL. Can't find dist packages without a MANIFEST file Run 'Build manifest' to generate one WARNING: Possible missing or corrupt 'MANIFEST' file. Nothing to enter for 'provides' field in metafile. JSON::PP 2.27300 is not available at /usr/local/lib/perl5/site_perl/CPAN/Meta.pm line 616. gmake[1]: *** [Makefile:435: master/Build] Error 255 gmake[1]: Leaving directory '/usr/ports/sysutils/munin-master/work/munin-2.0.27' *** Error code 1 Stop. make: stopped in /usr/ports/sysutils/munin-master What can I do to fix it? It asks to run: Build manifest - but where do I run this? Many thanks. Kaya ___ 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"
The ports collection has some serious issues
On Thu, 8 Dec 2016, Matt Smith wrote: On Dec 08 05:16, Daniil Berendeev wrote: Although portmaster is not releated to the FreeBSD project and is an outside tool, there aren't any alternatives from the project itself. So use it or die. Not a nice situation. People have been trying to get portmaster deprecated and removed from the handbook but have met with resistance. Well, yes. Because it works, has no dependencies, and there is no equivalent replacement. Except maybe portupgrade, which has legacy problems like poor default options. Every single week, somebody falsely accuses the ports tree of being broken but the accuser is the only one with the problem. What do they all have in common? They are portmaster users. I'll iterate, saying "portmaster works" means applying a very generous definition of "works". The recommended replacements are ports-mgmt/synth and ports-mgmt/poudriere. These build an entire package repository that the pkg tool can use but they do so in clean chrooted environments, and rebuild everything that's required to keep a consistent ABI. Synth is more designed for a single live system like a desktop or a single server, whereas poudriere is what the freebsd package build clusters use and is more designed for that type of usage. Worth taking a look. These are package builders. Technically preferable, given adequate disk space and memory, but not equivalent to portmaster. It's like saying git and svn are not equivalent to cvs. It's a shame the handbook hasn't been updated to give this information. Which information, in particular? A section on Poudriere was submitted, and I spent a fair amount of time editing it and getting it in there. As far as Synth or other information, I'm not aware of any pending Handbook or other documentation submissions. for starters: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214679 Previous PRs indicated that recommendations for portmaster and portupgrade were to be removed, but so far this PR has stalled. John --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ 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: The ports collection has some serious issues
On 15.12.2016 16:29, John Marino wrote: Although portmaster is not releated to the FreeBSD project and is an outside tool, there aren't any alternatives from the project itself. So use it or die. Not a nice situation. People have been trying to get portmaster deprecated and removed from the handbook but have met with resistance. Well, yes. Because it works, has no dependencies, and there is no equivalent replacement. Except maybe portupgrade, which has legacy problems like poor default options. Every single week, somebody falsely accuses the ports tree of being broken but the accuser is the only one with the problem. What do they all have in common? They are portmaster users. I'll iterate, saying "portmaster works" means applying a very generous definition of "works". Not really, no. Its not every week and often there is a misuse or miss-understanding of portmaster. With an argument like this you can also state there is every week a falsely accuse, because of poudriere. This would also be true (and is). The recommended replacements are ports-mgmt/synth and ports-mgmt/poudriere. These build an entire package repository that the pkg tool can use but they do so in clean chrooted environments, and rebuild everything that's required to keep a consistent ABI. Synth is more designed for a single live system like a desktop or a single server, whereas poudriere is what the freebsd package build clusters use and is more designed for that type of usage. Worth taking a look. These are package builders. Technically preferable, given adequate disk space and memory, but not equivalent to portmaster. It's like saying git and svn are not equivalent to cvs. I have a hard time to see git in this line. Its the way you use it. Yes, of course all three are code repositories. But one of them is a distributed repository and the other two are not. The differences are huge. Of course it also depends on your usage. I personally (means "heavily subjective) find git more than annoying. It lacks very important features (user management), is hard to use in automatic environments and make easy things (rename/delete branches) very hard. Other people really like all of this. It depends. So maybe the accusers just use the wrong tool? Greetings, Torsten ___ 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: The ports collection has some serious issues
On Thu, 15 Dec 2016 07:40:46 -0700 (MST) Warren Block wrote: > On Thu, 8 Dec 2016, Matt Smith wrote: > > > On Dec 08 05:16, Daniil Berendeev wrote: > >> > >> Although portmaster is not releated to the FreeBSD project and is > >> an outside tool, there aren't any alternatives from the project > >> itself. So use it or die. Not a nice situation. > > > > People have been trying to get portmaster deprecated and removed > > from the handbook but have met with resistance. > > Well, yes. Because it works, has no dependencies, and there is no > equivalent replacement. Except maybe portupgrade, which has legacy > problems like poor default options. That's a very minor issue, and an absurd excuse to rule-out portupgrade. ___ 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: (In)Stability of the Quarterly Branch
On Thu, 15 Dec 2016 14:16:18 +0100 David Demelier wrote: > 2016-11-16 13:17 GMT+01:00 Vlad K. : > > The quarterly branch (Q) is intended to provide a set of "stable" packages > > that in the lifetime of such a branch, receive only bug and security fixes. > > That is the theory and intent behind the branch. In practice, however: > > > > 1. The Q branch is cut off at predetermined dates (ie. not when it's stable > > and ready), and it is cut off from HEAD, thus including the state of ports > > at that moment. This breaks the promise of stability and guarantees that > > every 3 months there will be uncertainty as to whether the fresh new > > versions are working or not. There is no such thing as a "Pre-Quarterly > > repo" which would receive all updates for the NEXT Q branch-off, and which > > would freeze and stabilize for some time before branch-off. And even if it > > did, 3 months would be too short. > > > > It is effectively not much different from tracking HEAD and doing updates > > only every three months, with the added benefit that SOME security updates > > will come down sooner. But: > > > > 2. Unfortunately not all "security or bug-only fixes" are MFH'd, and as a > > bugzilla triager I've had the opportunity to observe this in practice. It > > can be as simple as accepting a minor upstream version bump, or as complex > > as requiring cherry-picking and backporting code if upstream mixes security, > > bug fixes with new features. It is none-the-less a manual work requiring > > ports-secteam to review and accept the patches. It is not clear who is > > supposed to do cherry-picked backporting if the patches to HEAD cannot be > > MFH'd as they are. It is also additional burden to the ports-secTEAM which > > at the moment is, effectively, one person. > > > > As it is obvious that the promise of a stable repo in its current form > > requires manpower and manual work which we do not have, my proposal is to > > abandon the promise of "security/bugfix" only changes and adopt the approach > > not unlike Gentoo's, in which a "STABLE" repository receives ALL the updates > > from HEAD, but only after certain criteria has been met, like minimal age of > > changes, no open issues, a certain battery of regression/integration/unit > > tests is performed, etc... > > > > The problem is that there are no tests in FreeBSD ports. All source > based systems I've tested: pkgsrc, FreeBSD ports, OpenBSD, Gentoo; > FreeBSD is the one that have the most instability. Not to mention > committers that commit without testing the port, just look at > www/redmine to get your point of view on that issue. Are your serious when you said, there're no tests on FreeBSD ports. I can tell you Xfce ports are tested with FreeBSD i386 9.3 and amd64 11.0 machines (on real hardware, no virtualization), and on poudriere with Gtk+ 3.20 (port version is not not in ports tree, it's defaut toolkits for the next stable release 4.14). For the LXQt desktop is the same thing (tested with official ports tree Qt5 and which one in plasma5 branch (on KDE repository). I'm also working on the Pantheon desktop (desktop environment of Elementary OS, I use Vala 0.30.2 and Vala 0.34.4, in order to test stability of applications. I use also OpenBSD macppc, it's piece of shit. WebKit browers are broken, Xfce components crash often, stable branch is outdated, fix are not propagated in stable branch. Personally I prefer the FreeBSD scheme, because I'm sure it's quite stable. > > On the other hand, your idea is indeed good and could be a good start. > Quaterly branches change too quickly. That's simple: each time I > install a new port, I'm behind 2 or 3 quarters the last one. So I > usually update all before installing the new one. > > What I want: a ports tree that matches the FreeBSD version like > OpenBSD. You have FreeBSD 11.0? You get a ports tree for that version > specifically. No major update, no breaking changes. Just bug fixes. > That will also simplify a lot FreeBSD ports by not having thousands of > conditional checking the FreeBSD version. > > Waiting for more stability, I really encourage people to use poudriere > to build packages to avoid breaking a system at each upgrade. > > Regards, > > -- > Demelier David > ___ > 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" -- olivier ___ 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: The ports collection has some serious issues
On 12/15/2016 09:49, Torsten Zuehlsdorff wrote: On 15.12.2016 16:29, John Marino wrote: Although portmaster is not releated to the FreeBSD project and is an outside tool, there aren't any alternatives from the project itself. So use it or die. Not a nice situation. People have been trying to get portmaster deprecated and removed from the handbook but have met with resistance. Well, yes. Because it works, has no dependencies, and there is no equivalent replacement. Except maybe portupgrade, which has legacy problems like poor default options. Every single week, somebody falsely accuses the ports tree of being broken but the accuser is the only one with the problem. What do they all have in common? They are portmaster users. I'll iterate, saying "portmaster works" means applying a very generous definition of "works". Not really, no. Its not every week and often there is a misuse or miss-understanding of portmaster. It is every week. Consider the FreeBSD forums as well. "misuse" and "misunderstanding" failures are attributed to the tool. Let's stop making excuses for portmaster. It is what it is and we've had years to evaluate it. With an argument like this you can also state there is every week a falsely accuse, because of poudriere. This would also be true (and is). I couldn't state that accurately. I can't recall any misuse reports (and I can't come up with a feasible case in my head right now) The recommended replacements are ports-mgmt/synth and ports-mgmt/poudriere. These build an entire package repository that the pkg tool can use but they do so in clean chrooted environments, and rebuild everything that's required to keep a consistent ABI. Synth is more designed for a single live system like a desktop or a single server, whereas poudriere is what the freebsd package build clusters use and is more designed for that type of usage. Worth taking a look. These are package builders. Technically preferable, given adequate disk space and memory, but not equivalent to portmaster. It's like saying git and svn are not equivalent to cvs. I have a hard time to see git in this line. Its the way you use it. Yes, of course all three are code repositories. But one of them is a distributed repository and the other two are not. The differences are huge. Of course it also depends on your usage. I personally (means "heavily subjective) find git more than annoying. It lacks very important features (user management), is hard to use in automatic environments and make easy things (rename/delete branches) very hard. Other people really like all of this. It depends. So maybe the accusers just use the wrong tool? The point is that you wouldn't start a new project with cvs. You may or may not transfer an existing project from cvs, but you're letting cvs die by attribution. The same should be for portmaster. Some users will never see the light. Let them suffer by their own hand. But for Pete's sake, don't recommend it to new users. That's not doing them any kind of service. Portmaster is not maintained. Since you put your name on it, you've made not a single commit to the repository, much less a new release. Yet there are PRs on it. Please, can we somehow discourage new people from starting on it? Anybody with a machine that doesn't have a resources to run poudriere or synth should not be building packages on that machine. Veterans have the option to use portmaster in a case like that, but it's not something that should be suggested to newbies. Now the discussion is sidetracked, but really nothing has improved since I tried to get a warning added to portmaster months ago. John --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ 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: (In)Stability of the Quarterly Branch
On 2016/12/15 16:01, Olivier Duchateau wrote: >> The problem is that there are no tests in FreeBSD ports. All source >> based systems I've tested: pkgsrc, FreeBSD ports, OpenBSD, Gentoo; >> FreeBSD is the one that have the most instability. Not to mention >> committers that commit without testing the port, just look at >> www/redmine to get your point of view on that issue. > Are your serious when you said, there're no tests on FreeBSD ports. I > can tell you Xfce ports are tested with FreeBSD i386 9.3 and amd64 > 11.0 machines (on real hardware, no virtualization), and on poudriere > with Gtk+ 3.20 (port version is not not in ports tree, it's defaut > toolkits for the next stable release 4.14). > > For the LXQt desktop is the same thing (tested with official ports > tree Qt5 and which one in plasma5 branch (on KDE repository). > > I'm also working on the Pantheon desktop (desktop environment of > Elementary OS, I use Vala 0.30.2 and Vala 0.34.4, in order to test > stability of applications. > > I use also OpenBSD macppc, it's piece of shit. WebKit browers are > broken, Xfce components crash often, stable branch is outdated, fix > are not propagated in stable branch. Personally I prefer the FreeBSD > scheme, because I'm sure it's quite stable. Most port committers will run compile tests any time they update a port: the better ones will test compilation on all supported FreeBSD versions and all hardware architectures they have access to (ie. generally i386 and amd64). Additionally the package build cluster will rebuild any modified ports within a few days for all of the OS versions and architectures the project tries to provide ports for: that's yet another level of validating the coding of the port itself. However, I believe the OP's point is that *we do not routinely run the software's own built-in regression tests for the packages we succeed in building*. This is something that is slowly coming. For instance, you can run 'make test' for many python, ruby or perl packages and see those tests being run. TEST_DEPENDS is pretty much standardized as the way to install dependencies required for testing nowadays. Yet another layer of package validation would be very good to have, but it isn't routine yet. Cheers, Matthew signature.asc Description: OpenPGP digital signature
Re: The ports collection has some serious issues
On Thu, 15 Dec 2016, RW via freebsd-ports wrote: On Thu, 15 Dec 2016 07:40:46 -0700 (MST) Warren Block wrote: On Thu, 8 Dec 2016, Matt Smith wrote: On Dec 08 05:16, Daniil Berendeev wrote: Although portmaster is not releated to the FreeBSD project and is an outside tool, there aren't any alternatives from the project itself. So use it or die. Not a nice situation. People have been trying to get portmaster deprecated and removed from the handbook but have met with resistance. Well, yes. Because it works, has no dependencies, and there is no equivalent replacement. Except maybe portupgrade, which has legacy problems like poor default options. That's a very minor issue, and an absurd excuse to rule-out portupgrade. I didn't rule it out. Portupgrade gets some of the defaults wrong, like not running all the 'make config' steps first. That's a legacy issue because if the default changes, it could conceivably cause problems for existing users. Beyond that, other than a dependency on Ruby, portupgrade at least exists in the same space as portmaster. ___ 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: The ports collection has some serious issues
On 15.12.2016 17:00, John Marino wrote: On 12/15/2016 09:49, Torsten Zuehlsdorff wrote: On 15.12.2016 16:29, John Marino wrote: Although portmaster is not releated to the FreeBSD project and is an outside tool, there aren't any alternatives from the project itself. So use it or die. Not a nice situation. People have been trying to get portmaster deprecated and removed from the handbook but have met with resistance. Well, yes. Because it works, has no dependencies, and there is no equivalent replacement. Except maybe portupgrade, which has legacy problems like poor default options. Every single week, somebody falsely accuses the ports tree of being broken but the accuser is the only one with the problem. What do they all have in common? They are portmaster users. I'll iterate, saying "portmaster works" means applying a very generous definition of "works". Not really, no. Its not every week and often there is a misuse or miss-understanding of portmaster. It is every week. Consider the FreeBSD forums as well. No, it isn't. Lets check the history. This is just a general statement. portmaster was added 2006 and the portstree startet in 1994. Yes, there are emotions in discussions and they are really needed to drive things, but we need to ensure to drive in the right direction. "misuse" and "misunderstanding" failures are attributed to the tool. Let's stop making excuses for portmaster. It is what it is and we've had years to evaluate it. I'm with you at this point. portmaster is incredible complex and hard to understand. Therefore it is easy to misue or to misunderstand. With an argument like this you can also state there is every week a falsely accuse, because of poudriere. This would also be true (and is). I couldn't state that accurately. I can't recall any misuse reports (and I can't come up with a feasible case in my head right now) I could. My colleague did some of them. :D Even i generate some of them. The recommended replacements are ports-mgmt/synth and ports-mgmt/poudriere. These build an entire package repository that the pkg tool can use but they do so in clean chrooted environments, and rebuild everything that's required to keep a consistent ABI. Synth is more designed for a single live system like a desktop or a single server, whereas poudriere is what the freebsd package build clusters use and is more designed for that type of usage. Worth taking a look. These are package builders. Technically preferable, given adequate disk space and memory, but not equivalent to portmaster. It's like saying git and svn are not equivalent to cvs. I have a hard time to see git in this line. Its the way you use it. Yes, of course all three are code repositories. But one of them is a distributed repository and the other two are not. The differences are huge. Of course it also depends on your usage. I personally (means "heavily subjective) find git more than annoying. It lacks very important features (user management), is hard to use in automatic environments and make easy things (rename/delete branches) very hard. Other people really like all of this. It depends. So maybe the accusers just use the wrong tool? The point is that you wouldn't start a new project with cvs. You may or may not transfer an existing project from cvs, but you're letting cvs die by attribution. The same should be for portmaster. Some users will never see the light. Let them suffer by their own hand. But for Pete's sake, don't recommend it to new users. That's not doing them any kind of service. I see recommendations for poudriere or synth, but not for portmaster. And i give them too. But both are tools which are not feasible for every situation. I often have a hard time to get them their space they need to make things better. So it would be a good idea under which circumstances portmaster is a good choice and whenever it is not. Portmaster is not maintained. Since you put your name on it, you've made not a single commit to the repository, much less a new release. Yet there are PRs on it. No excuses here. You are right, but its another store. I approved a commit which than breaks portmaster even after very good testing. And that make me even more cautious. But also i'm not allowed to change the code or do changes by myself, so its no surprise its very hard and i considered to drop my maintainer line multiple times. Thats just beside that the code is not written in a way which supports testing. So there is a very big risk in every change. I started to rewrite it in an private repo, but since it works (i could close many PRs) it really is at the bottom of my list. Please, can we somehow discourage new people from starting on it? Anybody with a machine that doesn't have a resources to run poudriere or synth should not be building packages on that machine. I provide a poudriere server for my customers. Its not to nice to use, but they can configure it like the
Re: (In)Stability of the Quarterly Branch
Vlad K. wrote: The quarterly branch (Q) is intended to provide a set of "stable" packages that in the lifetime of such a branch, receive only bug and security fixes. That is the theory and intent behind the branch. In practice, however: 1. The Q branch is cut off at predetermined dates (ie. not when it's stable and ready), and it is cut off from HEAD, thus including the state of ports at that moment. This breaks the promise of stability and guarantees that every 3 months there will be uncertainty as to whether the fresh new versions are working or not. There is no such thing as a "Pre-Quarterly repo" which would receive all updates for the NEXT Q branch-off, and which would freeze and stabilize for some time before branch-off. And even if it did, 3 months would be too short. It is effectively not much different from tracking HEAD and doing updates only every three months, with the added benefit that SOME security updates will come down sooner. But: 2. Unfortunately not all "security or bug-only fixes" are MFH'd, and as a bugzilla triager I've had the opportunity to observe this in practice. It can be as simple as accepting a minor upstream version bump, or as complex as requiring cherry-picking and backporting code if upstream mixes security, bug fixes with new features. It is none-the-less a manual work requiring ports-secteam to review and accept the patches. It is not clear who is supposed to do cherry-picked backporting if the patches to HEAD cannot be MFH'd as they are. It is also additional burden to the ports-secTEAM which at the moment is, effectively, one person. As it is obvious that the promise of a stable repo in its current form requires manpower and manual work which we do not have, my proposal is to abandon the promise of "security/bugfix" only changes and adopt the approach not unlike Gentoo's, in which a "STABLE" repository receives ALL the updates from HEAD, but only after certain criteria has been met, like minimal age of changes, no open issues, a certain battery of regression/integration/unit tests is performed, etc... The key, I believe, is in automation which we can achieve with this, and with that offer at least SOME level of stability without broken promises. The key to this automation is no manual review, which can only be achieved if we accept ALL changes, but stabilized to certain degree. The idea of a "stable" repository is a valiant one, we definitely need it if we want to increase the usage of FreeBSD in production as more than just a base OS that does routing and ZFS storage -- namely production use of stable ports. And IMHO we only need to balance between how stable we can provide/guarantee it and what resources and manpower we have available to do so. What are the community's thoughts on this? That's what it needed but people charging through new versions and linuxifying FreeBSD screwed the pooch... This conversation/thread should have happened 2 years back. Michelle ___ 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: The ports collection has some serious issues
On 12/15/2016 10:31, Torsten Zuehlsdorff wrote: On 15.12.2016 17:00, John Marino wrote: It is every week. Consider the FreeBSD forums as well. No, it isn't. Lets check the history. This is just a general statement. portmaster was added 2006 and the portstree startet in 1994. Can you agree that if you combine both this list and issues that arise on the FreeBSD forums that portmaster users talk about problems frequently? Does it matter if it's weekly or biweekly? It seems to happen all the time on the forums, but I'm not going scan them to prove an exact frequency. I could. My colleague did some of them. :D Even i generate some of them. As a side discussion I would like to know what they are and if they are valid for Synth as well. I see recommendations for poudriere or synth, but not for portmaster. And i give them too. Unfortunately portmaster get a lot of positive press on the forums. Portmaster is not maintained. Since you put your name on it, you've made not a single commit to the repository, much less a new release. Yet there are PRs on it. No excuses here. You are right, but its another store. I approved a commit which than breaks portmaster even after very good testing. And that make me even more cautious. But also i'm not allowed to change the code or do changes by myself, so its no surprise its very hard and i considered to drop my maintainer line multiple times. Thats just beside that the code is not written in a way which supports testing. So there is a very big risk in every change. I started to rewrite it in an private repo, but since it works (i could close many PRs) it really is at the bottom of my list. Interesting, but not surprising. I know it was claimed to negate my good point that such a piece of software needs a maintainer, but it had to be somebody with deep level knowledge with both the capability and *authority* to make the changes. So now users think it's maintained and have a false confidence in it. But with your name on it, I can't push for it to be marked "deprecated" (with no expiration, that's important) anymore. It's a loophole. Please, can we somehow discourage new people from starting on it? Anybody with a machine that doesn't have a resources to run poudriere or synth should not be building packages on that machine. I provide a poudriere server for my customers. Its not to nice to use, but they can configure it like the need and without the pressure on their own server. Maybe we need something like this to make it easier to abandon portmaster. For i386 and amd64 users, synth does not require more resources than portmaster. People on those platforms can't use "resources" as a reason not to use Synth. From what I can tell, portmaster people hate what they consider unnecessary rebuilds which both poudriere and synth (currently [1]) do, but it's this avoidance of rebuilds that cause all their problems. So providing them a poudriere service wouldn't solve that "problem" for them. John [1] I've got it on my todo list to provide a new method that would eliminate the "my builder just rebuilt 150 packages, but pkg(8) only upgraded 2 packages" issue that some users don't want to see. It's a lot more complicated than the conservative yet bulletproof approach currently used by poudriere and synth. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ 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: The ports collection has some serious issues
On 15.12.2016 17:46, John Marino wrote: On 12/15/2016 10:31, Torsten Zuehlsdorff wrote: On 15.12.2016 17:00, John Marino wrote: It is every week. Consider the FreeBSD forums as well. No, it isn't. Lets check the history. This is just a general statement. portmaster was added 2006 and the portstree startet in 1994. Can you agree that if you combine both this list and issues that arise on the FreeBSD forums that portmaster users talk about problems frequently? Yes, of course. I wasn't serious with this point and just want to degrade a little of the emotion to get back to a more technical and solvable level. I could. My colleague did some of them. :D Even i generate some of them. As a side discussion I would like to know what they are and if they are valid for Synth as well. Good question. I will ask my colleague to check; hopefully he does it also. I see recommendations for poudriere or synth, but not for portmaster. And i give them too. Unfortunately portmaster get a lot of positive press on the forums. Okay, that is just the opposite of the mailinglist. For bugzilla we have the helpful team around koops, which adjust the PRs. Maybe we should install something like that for the forum? Or just print a warning whenever portmaster is used (which would be much easier). We even can automatically link the word portmaster to an website, which gives more information and some warning. Portmaster is not maintained. Since you put your name on it, you've made not a single commit to the repository, much less a new release. Yet there are PRs on it. No excuses here. You are right, but its another store. I approved a commit which than breaks portmaster even after very good testing. And that make me even more cautious. But also i'm not allowed to change the code or do changes by myself, so its no surprise its very hard and i considered to drop my maintainer line multiple times. Thats just beside that the code is not written in a way which supports testing. So there is a very big risk in every change. I started to rewrite it in an private repo, but since it works (i could close many PRs) it really is at the bottom of my list. Interesting, but not surprising. I know it was claimed to negate my good point that such a piece of software needs a maintainer, but it had to be somebody with deep level knowledge with both the capability and *authority* to make the changes. So now users think it's maintained and have a false confidence in it. But with your name on it, I can't push for it to be marked "deprecated" (with no expiration, that's important) anymore. It's a loophole. A breakable loophole. Since i figured out, that a complete rewrite would be a better solution, than the permanent danger of an very hard to test software, we can drop my name from it. Please, can we somehow discourage new people from starting on it? Anybody with a machine that doesn't have a resources to run poudriere or synth should not be building packages on that machine. I provide a poudriere server for my customers. Its not to nice to use, but they can configure it like the need and without the pressure on their own server. Maybe we need something like this to make it easier to abandon portmaster. For i386 and amd64 users, synth does not require more resources than portmaster. People on those platforms can't use "resources" as a reason not to use Synth. From what I can tell, portmaster people hate what they consider unnecessary rebuilds which both poudriere and synth (currently [1]) do, but it's this avoidance of rebuilds that cause all their problems. So providing them a poudriere service wouldn't solve that "problem" for them. It does. Since they are not aware of the "unnecessary" rebuilds, its no "problem" anymore. If you have to watch rebuilding 150 ports just for an update of 2 ports, its a complete different story. If pkg only update 2 ports and you can't see the work behind them, everything is fine. Its a little bit psychological. Greetings, Torsten ___ 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: The ports collection has some serious issues
I want to talk about another issue: the testing of ports framework We usually test our ports via poudriere or synth. We have a greate ports framework to help us build software, and we only need to write a few lines of code to leveage it. But ... where is the testing of the framework ? Those code under Mk/* is quite complex nowaday, and the requirement is keeping changing (for example, more and more new languages appear, helpers need to be added into ports framework). This will be a big barrier for maintenance. Is time to build a next generation framework? I think about this issue for a few weeks already, but still not get a good answer. I only sorted out some principles and want to hear more feedback: 1) Select a modern scripting language Lots of testing methodology implemented in those languages. Most of them are high-level. The cost of maintenance (hopefully) reduce. So, I think this is a good starting point. 2) Not to abandon tons of Makfile 3) Not to introduce any new dependency for a end user Just my imagination: In order to keep (2) and (3), I will use Python to build a system doing Makfile code generation. The ports framework managers and porters just write some Python function and testing code, then generate a proper tested and stable Makefiles for users. -- Iblis Lin 林峻頤 ___ 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: The ports collection has some serious issues
John Marino wrote on 2016/12/15 17:46: [1] I've got it on my todo list to provide a new method that would eliminate the "my builder just rebuilt 150 packages, but pkg(8) only upgraded 2 packages" issue that some users don't want to see. It's a lot more complicated than the conservative yet bulletproof approach currently used by poudriere and synth. This is interesting case - we are running own Poudriere repo and I am fine with it. But I am a bit nervous when I know 150 packages was rebuilt and just 2 upgraded by pkg. In this case I want pkg to update (reinstall) all of them. If something changed so that 150 packages must be rebuilt why pkg doesn't reinstall them? Isn't it the possible place for problems after upgrade? Mirek ___ 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"
Auditorías a través del Buzón Tributario
En línea y en Vivo / Para todo su Equipo con una sola Conexión Auditorías a través del Buzón Tributario 29 de diciembre - Online en Vivo - 10:00 a 13:00 Hrs A través de esta Capacitación Online en Vivo entérese cuáles son los sectores involucrados, en qué consisten dichas auditorías, a qué segmentos van dirigidas y cómo se tendrán que resolver las inconformidades en términos del Buzón Tributario. Descubra cómo las personas físicas y los pequeños negocios inscritos en el Régimen de Incorporación Fiscal (RIF) son los sectores que más han resentido los cambios entrados en vigor en 2014, ya que todavía hay carencias técnicas y tecnológicas. "Pregunte por nuestra Promoción Navideña" TEMARIO: 1. Qué son los trámites por Buzón Tributario y Auditorías Electrónicas del SAT. 2. Marco legal del Buzón Tributario y las Auditorías. 3. A partir de cuándo es obligatoria la contabilidad electrónica. 4. Vigencia de la notificación vía e-mail: Se incumple con el pago de impuestos por no tener acceso a internet. ...¡Y mucho más! ¿Requiere la información a la Brevedad? responda este email con la palabra: Info - Buzón. centro telefónico: 018002129393 Lic. Arturo López Coordinador de Evento ¿Demasiados mensajes en su cuenta? Responda este mensaje indicando que solo desea recibir CALENDARIO y sólo recibirá un correo al mes. Si desea cancelar la suscripción, solicite su BAJA. ___ 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: The ports collection has some serious issues
On 12/15/16 09:40, Warren Block wrote: > On Thu, 8 Dec 2016, Matt Smith wrote: > >> On Dec 08 05:16, Daniil Berendeev wrote: >>> >>> Although portmaster is not releated to the FreeBSD project and is an >>> outside tool, there aren't any alternatives from the project itself. So >>> use it or die. Not a nice situation. >> >> People have been trying to get portmaster deprecated and removed from >> the handbook but have met with resistance. > > Well, yes. Because it works, has no dependencies, and there is no > equivalent replacement. [...] Warren, you have hit the nail on the head. -- George ___ 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: The ports collection has some serious issues
On Thu, Dec 15, 2016 at 01:18:05PM -0500, George Mitchell wrote: > On 12/15/16 09:40, Warren Block wrote: > > On Thu, 8 Dec 2016, Matt Smith wrote: > > > >> On Dec 08 05:16, Daniil Berendeev wrote: > >>> > >>> Although portmaster is not releated to the FreeBSD project and is an > >>> outside tool, there aren't any alternatives from the project itself. So > >>> use it or die. Not a nice situation. > >> > >> People have been trying to get portmaster deprecated and removed from > >> the handbook but have met with resistance. > > > > Well, yes. Because it works, has no dependencies, and there is no > > equivalent replacement. [...] > > Warren, you have hit the nail on the head. -- George +1 I never have problems with portmaster. (But portupgrade could at times be an utter mess, I never looked back after switching to portmaster many years ago.) And I'm not at all interested in running poudriere or synth, thank you. Peter ___ 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: The ports collection has some serious issues
On Thu, 15 Dec 2016 19:31:22 +0100 list-freebsd-po...@jyborn.se wrote: > On Thu, Dec 15, 2016 at 01:18:05PM -0500, George Mitchell wrote: > > On 12/15/16 09:40, Warren Block wrote: > > > On Thu, 8 Dec 2016, Matt Smith wrote: > > > > > >> On Dec 08 05:16, Daniil Berendeev wrote: > > >>> > > >>> Although portmaster is not releated to the FreeBSD project and is an > > >>> outside tool, there aren't any alternatives from the project itself. So > > >>> use it or die. Not a nice situation. > > >> > > >> People have been trying to get portmaster deprecated and removed from > > >> the handbook but have met with resistance. > > > > > > Well, yes. Because it works, has no dependencies, and there is no > > > equivalent replacement. [...] > > > > Warren, you have hit the nail on the head. -- George > > +1 > > I never have problems with portmaster. > (But portupgrade could at times be an utter mess, > I never looked back after switching to portmaster > many years ago.) > > And I'm not at all interested in running poudriere > or synth, thank you. > It seems that if people happy with portmaster keep silent, others will assume it's okay to try to dismiss it; so here am I, happy with portmaster. I could switch to something else that is feature wise similar; but if it would not written in some quasi-obselete/niche/hipster programing language or involve admin/config tasks like creating repos. Until a challenger appears, I'm just going to use and recommend portmaster. Happy bsding everybody -- Matthieu pgplStNvzBqaD.pgp Description: OpenPGP digital signature
Re: No port should need root for make fetch
On 2016-Dec-15 09:43:51 +0100, Mathieu Arnold wrote: >Le 14/12/2016 à 06:17, Peter Jeremy a écrit : >> On 2016-Dec-13 21:32:36 +0100, "Julian H. Stacey" wrote: >>> IMO No port should need root for >>> cd /usr/ports; make -i fetch >> In a stock FreeBSD install, all ports require root to both fetch and build. >> You have customised your system in a non-standard way so you are getting >> non-standard behaviour which doesn't match you expectations. > >That is plain not true. By default, /usr/ports/distfiles is mode 0775 root:wheel and the only member of wheel is root. Fetching a port requires writing to /usr/ports/distfiles, hence root is the only user that can fetch distfiles. Likewise, by default, ports are built it /usr/ports/CATEGORY/NAME/work. /usr/ports/CATEGORY/NAME is only writable by root so only root can create the work directory in which to build ports. If you change the above defaults (which I suspect most people do) then you are correct that only a handful of ports need root to fetch or build (and I think that is still too many) - but I explicitly specified "stock install". -- Peter Jeremy signature.asc Description: PGP signature
CFT: OpenVPN 2.4 port update for FreeBSD
Greetings, I've put up an OpenVPN 2.4-rc1 port for FreeBSD up for testing. Get it from https://people.freebsd.org/~mandree/openvpn-2.4.r1-v1.tar.xz Or review the diff at https://reviews.freebsd.org/D8813 Cheers, Matthias signature.asc Description: OpenPGP digital signature
can somebody commit this fix for isc-dhcp43 port?
net/isc-dhcp43-server: rc script does not play nice with service -e https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213463 Reported at October, added patch and poudriere log but still uncommitted. Reminded at November and? Still not committed. Miroslav Lachman ___ 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: The ports collection has some serious issues
John Marino freebsd.contact at marino.st on Thu Dec 15 16:46:54 UTC 2016 wrote: > For i386 and amd64 users, synth does not require more resources than > portmaster. People on those platforms can't use "resources" as a reason > not to use Synth. From what I can tell, portmaster people hate what > they consider unnecessary rebuilds which both poudriere and synth > (currently [1]) do, but it's this avoidance of rebuilds that cause all > their problems. Also on Thu Dec 15 16:00:47 UTC 2016: > Anybody with a machine that doesn't have a resources to run poudriere or > synth should not be building packages on that machine. Veterans have > the option to use portmaster in a case like that, but it's not something > that should be suggested to newbies. Note: My FreeBSD usage is not from any of the main families of usage. Do not think that I expect things to be biased for my use. My kind of context may well be implicitly not intended to be covered by the above. I wonder if build tool recommendations need some breakout by user categories rather than one grand overall recommendation. This might be just a note of "no specific recommendation" for some category(s). I use my context below as a potential example. I primarily experiment with self hosting FreeBSD activities on powerpc64, powerpc, armv6/armv7, and aarch64, reporting issues that I find. For the powerpc family this has focused on fairly modern clang usage for buildworld and buildkernel -- as well as building ports. This tends to fit me with "developer" and less with "user" in some respects. If synth was buildable and usable on powerpc64, powerpc, armv6/armv7, and aarch64 I likely would have tried it. (I do not want to be using different self-hosting techniques per TARGET_ARCH but instead use one set of techniques on all.) Building synth would take up more time and space than portmaster but I could have tolerated such. For the SD card contexts I tend to have an SSD for the root file system. This likely is uncommon. Only the old powerpc's have fewer than 4 cores/processors supported by FreeBSD: one armv7 has 8 but FreeBSD supports only 4. buildworld with -j 4 or so does take a long time on the armv7 machines (for example). Of course there are large differences in performance compared to modern amd64's. When I tried portupgrade over a time I had problems with ruby in these environments. (amd64 went okay.) I eventually backed off, figuring I'd retry after some significant time in case they were temporary issues. Other than backups/recovery media I have one powerpc64 SSD for experiments, one powerpc SSD, one armv7 SSD (and an SD card) per single board computer type, and the same for the one aarch64 single board computer. Definitely not build-once/distribute-many generally. (But the armv7 context could do a little of that as I'm currently structuring things.) After "pkg autoremove" "portmaster --list-origins" lists 20-30 or so ports in each case. Before the autoremove "pkg info | wc" is under 100 as I remember. I sometimes have patches to ports involved when someone asks me to test such for something that I've reported. And because of binutils problems for powerpc64 I use older versions from svn in the contexts that I deal with targeting powerpc64's (that includes the devel/powerpc64-binutils slave port). For a time devel/powerpc64-gcc could not finish buildworld unless I used an older vintage from svn. I really do use devel/powerpc64-gcc and devel/powerpc64-binutils and devel/powerpc64-xtoolchain-gcc on a powerpc64: a "self hosted cross build" of sorts. Getting devel/powerpc64-gcc installed on a powerpc64 requires a work-around because it is not a true cross-build and some things are not the same if the target architecture is not distinct: I'm operating outside the intended usage model. The work around involves copying/moving some files to the right place/name in the staging area so that installation can find them and complete. [I also use amd64 FreeBSD under virtualbox in another operating system. This context has more to it but is still likely less than is typical.] [Ignoring amd64:] If I had been able to use synth on the variety of machines it would appear that the contribution of my time preferences might have eventually stopped my use. (Not the number of ports rebuilt as such but the systematic time spent.) "Might" because for my context it is not obvious up front what my judgement might be after a trail period. I'm not sure what I would have done about issues like devel/powerpc64-gcc being built and installed on a powerpc64 machine and needing a work around. Or testing patches for ports. I did not try to figure it out since I since I discovered synth was not an option first. I configure to avoid "disk" space issues generally (SSD root filesystems normally, with plenty of space). RAM varies from 1G to 2G Bytes over the armv7's, aarch64, and some powerpc's, but for powerpc64 there is more RAM: 8G, 12G, or 16G Bytes.
Re: The ports collection has some serious issues
Matthieu Volat wrote: On Thu, 15 Dec 2016 19:31:22 +0100 list-freebsd-po...@jyborn.se wrote: On Thu, Dec 15, 2016 at 01:18:05PM -0500, George Mitchell wrote: On 12/15/16 09:40, Warren Block wrote: On Thu, 8 Dec 2016, Matt Smith wrote: On Dec 08 05:16, Daniil Berendeev wrote: Although portmaster is not releated to the FreeBSD project and is an outside tool, there aren't any alternatives from the project itself. So use it or die. Not a nice situation. People have been trying to get portmaster deprecated and removed from the handbook but have met with resistance. Well, yes. Because it works, has no dependencies, and there is no equivalent replacement. [...] Warren, you have hit the nail on the head. -- George +1 I never have problems with portmaster. (But portupgrade could at times be an utter mess, I never looked back after switching to portmaster many years ago.) And I'm not at all interested in running poudriere or synth, thank you. It seems that if people happy with portmaster keep silent, others will assume it's okay to try to dismiss it; Yup so here am I, happy with portmaster. Don't worry, the people that have the power will dismiss it when they deem you need to "upgrade" to using synth or poudreire... oh and don't worry they'll remove distfiles and the previous 4 versions of the distfiles so that you can't keep your own local copy running, especially if you publish how to use it yourself. I could switch to something else that is feature wise similar; but if it would not written in some quasi-obselete/niche/hipster programing language or involve admin/config tasks like creating repos. Until a challenger appears, I'm just going to use and recommend portmaster. Same. Regards, Michelle ___ 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"
sysutils/php56-fileinfo exit signal Segmentation fault
I am running webmail Roundcube on many machines but on one machine file upload (attachment) doesn't work. I tracked it down to PHP extension fileinfo. Everytime I tried to upload a file I got this error in Apache error log: [Fri Dec 16 02:35:27.775113 2016] [core:notice] [pid 6883] AH00052: child pid 6890 exit signal Segmentation fault (11) Sometimes [Fri Dec 16 02:36:02.110390 2016] [core:notice] [pid 6883] AH00052: child pid 6998 exit signal Bus error (10) If fileinfo extension is disabled (removed ext-20-fileinfo.ini from /usr/local/etc/php/) upload works fine. I tried to change the order of extension but it doesn't change anything if it is last or second or anywhere in the middle of the list. I don't know what can be wrong on this machine because all machines have pkgs from the same poudriere repo. All are running Apache 2.4 and PHP 5.6. Does anybody have some idea how to solve this? (I cannot disable fileinfo because it is needed by other websites on this machine) Miroslav Lachman ___ 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: The ports collection has some serious issues
> Here, it doesn't look like that. Don't forget that /usr/ports/distfiles > accumulates old versions and must be manually cleaned out from time to > time. portmaster has a couple of options to remove distfiles that are > not needed. > > % du -hd0 /usr/ports > 8.1G/usr/ports > % du -hd0 /usr/ports/distfiles > 6.5G/usr/ports/distfiles > > After copying that to /tmp and deleting distfiles entirely: > > % du -hd0 /tmp/usr/ports > 1.4G/tmp/usr/ports Well, I know that, I were trying to tell that portsnap(8) is fetching HEAD by default and I didn't find any way to change that behavior. So the only way to pick another branch would be fetching the entire svn repository. I need it for development purposes also, so anyway I'd have to do that. But the size of the svn repository causes pure pain. Subversion is not intended for development style that requires keeping lots of branches and tags. Everyone knows that. At the moment, the repository takes ~/> du -h ports-fbsdsvn/ 42Gports-fbsdsvn/ In git, Mercurial, bazaar, well, any modern version control system you can create tons of branches, tags without wasting space or time. -- Cheers~ PGP key fingerprint: 07B3 2177 3E27 BF41 DC65 CC95 BDA8 88F1 E9F9 CEEF You can retrieve my public key at pgp.mit.edu. ___ 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: The ports collection has some serious issues
On 2016-Dec-15 19:31:22 +0100, list-freebsd-po...@jyborn.se wrote: >On Thu, Dec 15, 2016 at 01:18:05PM -0500, George Mitchell wrote: >> On 12/15/16 09:40, Warren Block wrote: >> > On Thu, 8 Dec 2016, Matt Smith wrote: >> > >> >> On Dec 08 05:16, Daniil Berendeev wrote: >> >>> >> >>> Although portmaster is not releated to the FreeBSD project and is an >> >>> outside tool, there aren't any alternatives from the project itself. So >> >>> use it or die. Not a nice situation. >> >> >> >> People have been trying to get portmaster deprecated and removed from >> >> the handbook but have met with resistance. >> > >> > Well, yes. Because it works, has no dependencies, and there is no >> > equivalent replacement. [...] >> >> Warren, you have hit the nail on the head. -- George > >+1 > >I never have problems with portmaster. I don't know about never - I think I managed to get it into a dependency loop once - but I've never had any issues that I could not resolve or that would entice me to look at an alternative. >(But portupgrade could at times be an utter mess, >I never looked back after switching to portmaster >many years ago.) Likewise, portupgrade would explode and shower my system with bits of corrupt database to often for comfort. At least part of that was caused by portupgrade depending on quite a few other ports and getting confused when it updated things whilst it was using them. >And I'm not at all interested in running poudriere >or synth, thank you. Interestingly, the most vocal proponent of deleting portmaster and portupgrade is the author/maintainer of synch. -- Peter Jeremy signature.asc Description: PGP signature
Re: The ports collection has some serious issues
On Fri, Dec 16, 2016 at 6:42 AM, Peter Jeremy wrote: > On 2016-Dec-15 19:31:22 +0100, list-freebsd-po...@jyborn.se wrote: >>On Thu, Dec 15, 2016 at 01:18:05PM -0500, George Mitchell wrote: > >>(But portupgrade could at times be an utter mess, >>I never looked back after switching to portmaster >>many years ago.) > > Likewise, portupgrade would explode and shower my system with bits of > corrupt database to often for comfort. At least part of that was caused > by portupgrade depending on quite a few other ports and getting confused > when it updated things whilst it was using them. > FWIW, I'm a happy portupgrade user. Yes - sometimes it breaks, but it is quite rare, and I am able to fix the breakage when it happens. So for me it is "good enough". >>And I'm not at all interested in running poudriere >>or synth, thank you. > > Interestingly, the most vocal proponent of deleting portmaster and > portupgrade is the author/maintainer of synch. I won't say "never". But I feel that both package builders (poudriere, synth) need some more time to shake out more issues / bugs and get into a better shape first. This isn't based on any specific problems or bugs, more a "felleing2 based on people's feedback in the forums and on mailing lists. If I was interested in package builders, I would spend some time helping to test them. Since my interests related to FreeBSD is on other things / tools / whatever, I spend my "FreeBSD time" on those other things instead. HTH -- Regards, Torfinn Ingolfsen ___ 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: The ports collection has some serious issues
On Thu, Dec 15, 2016 at 9:42 PM, Peter Jeremy wrote: > On 2016-Dec-15 19:31:22 +0100, list-freebsd-po...@jyborn.se wrote: > >On Thu, Dec 15, 2016 at 01:18:05PM -0500, George Mitchell wrote: > >> On 12/15/16 09:40, Warren Block wrote: > >> > On Thu, 8 Dec 2016, Matt Smith wrote: > >> > > >> >> On Dec 08 05:16, Daniil Berendeev wrote: > >> >>> > >> >>> Although portmaster is not releated to the FreeBSD project and is an > >> >>> outside tool, there aren't any alternatives from the project > itself. So > >> >>> use it or die. Not a nice situation. > >> >> > >> >> People have been trying to get portmaster deprecated and removed from > >> >> the handbook but have met with resistance. > >> > > >> > Well, yes. Because it works, has no dependencies, and there is no > >> > equivalent replacement. [...] > >> > >> Warren, you have hit the nail on the head. -- George > > > >+1 > > > >I never have problems with portmaster. > > I don't know about never - I think I managed to get it into a dependency > loop once - but I've never had any issues that I could not resolve or > that would entice me to look at an alternative. > > >(But portupgrade could at times be an utter mess, > >I never looked back after switching to portmaster > >many years ago.) > > Likewise, portupgrade would explode and shower my system with bits of > corrupt database to often for comfort. At least part of that was caused > by portupgrade depending on quite a few other ports and getting confused > when it updated things whilst it was using them. > > >And I'm not at all interested in running poudriere > >or synth, thank you. > > Interestingly, the most vocal proponent of deleting portmaster and > portupgrade is the author/maintainer of synch. > > -- > Peter Jeremy > Just to add another voice of those who use portmaster on a regular basis. I moved to portmaster about seven years ago and have has very few issues with it. I have had issues building ports from time to time, but it's been a long time since i hit one that was not a problem with the port... often related to the options I use. I like that it has no dependencies. I like that it is very stable. There are things I would like to see changed, but I would be very upset to lose it. Since it is stable, the only way I would lose it is if the underlying port structure changed in a way that required work on it. Saying that synth and poudriere are replacements for portmaster/portupgrade simply indicate lack of familiarity with my (and others) use cases. I have used synth and it is excellent, but not on my development system where everything is built from source and I hope always will be. I have found portupgrade too fragile for the reasons mentioned. I had to clean up a mangled database once too often. (Yes, it is a flat text db, so it can be fixed manually, but it is NOT fun!) -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ 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: (In)Stability of the Quarterly Branch
2016-12-15 17:25 GMT+01:00 Matthew Seaman : > On 2016/12/15 16:01, Olivier Duchateau wrote: >>> The problem is that there are no tests in FreeBSD ports. All source >>> based systems I've tested: pkgsrc, FreeBSD ports, OpenBSD, Gentoo; >>> FreeBSD is the one that have the most instability. Not to mention >>> committers that commit without testing the port, just look at >>> www/redmine to get your point of view on that issue. > >> Are your serious when you said, there're no tests on FreeBSD ports. I >> can tell you Xfce ports are tested with FreeBSD i386 9.3 and amd64 >> 11.0 machines (on real hardware, no virtualization), and on poudriere >> with Gtk+ 3.20 (port version is not not in ports tree, it's defaut >> toolkits for the next stable release 4.14). >> >> For the LXQt desktop is the same thing (tested with official ports >> tree Qt5 and which one in plasma5 branch (on KDE repository). >> >> I'm also working on the Pantheon desktop (desktop environment of >> Elementary OS, I use Vala 0.30.2 and Vala 0.34.4, in order to test >> stability of applications. >> >> I use also OpenBSD macppc, it's piece of shit. WebKit browers are >> broken, Xfce components crash often, stable branch is outdated, fix >> are not propagated in stable branch. Personally I prefer the FreeBSD >> scheme, because I'm sure it's quite stable. > > Most port committers will run compile tests any time they update a port: > the better ones will test compilation on all supported FreeBSD versions > and all hardware architectures they have access to (ie. generally i386 > and amd64). > I'm not talking about being sure that the port builds, but that the software works. This is a next step that is too often forgotten. For example I remember several years ago having a problem with audio/mumble. The port was building fine, the window opened fine but it was impossible to speak because there was a problem regarding the CELT libraries IIRC. That a port build is nice, that it works is better. And it's the same thing for www/redmine, each time I install it on a fresh machine, `service redmine start` won't start (after configuring of course) because the Gemfile is broken again. These are not the only ones. Glade also suffers a bug that makes it almost unusable. > Additionally the package build cluster will rebuild any modified ports > within a few days for all of the OS versions and architectures the > project tries to provide ports for: that's yet another level of > validating the coding of the port itself. > > However, I believe the OP's point is that *we do not routinely run the > software's own built-in regression tests for the packages we succeed in > building*. This is something that is slowly coming. For instance, you > can run 'make test' for many python, ruby or perl packages and see those > tests being run. TEST_DEPENDS is pretty much standardized as the way to > install dependencies required for testing nowadays. > Yes, I fully understand the requirements of such tests. I just would like that maintainers test the port by building it and *by running* them. This is time consuming for sure, but if the maintainers have no time, then just keep an old but fully working version :-) Regards, -- Demelier David ___ 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: The ports collection has some serious issues
On Mon, 12 Dec 2016, at 17:20, Julian Elischer wrote: > > Have you considered using things like poudriere that would allow you to > > build > > your own repository with your own set of packages and options. > > > > You will benefit: > > - ability to use pkg for your upgrades > > - ability to use customize your packages > > - safe rebuild process (in case of broken ABI) > > > > Best regards, > > Bapt > I'm actually slowly moving to this if I can work out how to specify my > own chroot image, and a few other things I need to tweak. (my own sets > of patches to add). Hi Julian, I've been doing this with poudriere + pkg + git for a couple of years now very happily, using a lagging ports checkout (similar to the quarterly branch but taken at our convenience), and git rebasing our custom patches so they "float" up to the top. We're using it at iwantmyname.com now as well. The guts of it is: - use poudriere as usual but with a git-backed /usr/ports - store custom patches in /usr/ports and push to https://github.com/ideegeo/ports/ until they get committed in FreeBSD ports tree - git rebase periodically to pull in shiny bits from git://github.com/freebsd/freebsd-ports master branch - ansible pkg triggers a poudriere run whenever we add a new package to the list - these are made available via our pkg repo to our servers - in practice, ansible is used to set up the whole stuff from scratch including letsencrypt certs for the https://pkg.example.org/ but these are the pre-automation steps I started with. Here are the raw notes from our wiki and that should be sufficient for you to try this out on a test VM somewhere. I assume I've forgotten stuff or made errors but promise to blog it over Christmas with a longer explanation. https://gist.github.com/dch/ec2693c051c66dcd2f17b30fc575a910 BTW I'm not exactly sure what you mean about a custom chroot image, but I imagine you can fiddle with the poudriere base in zroot/poudriere/jails/11_amd64 to your heart's content and it will be used during the build. A+ Dave ___ 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"
