How to hotplug pci/e devices in freeBSD? (Or How to remove and rescan/re-enumerate pci device?)
I'm looking for a way to refresh/re-enumerate the pci device list. In Linux, you can remove a particular pci device, and then after preforming a "rescan" the device will appear again. In Linux it is done by: echo 1 > /sys/bus/pci/devices/.../remove echo 1 > /sys/bus/pci/rescan I'm looking for a similar functionality in freeBSD. *What do I want to achieve?* I'm using freeBSD and my pcie device can be reset from the host. But when it boots again, it's uncommunicative, so I want to rescan the pci devices in order to initiate a new connection between the host and the device. Any idea would be appreciated, even if it takes some coding effort. Thanks! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[SOLVED] Re: >r280312 - r280332 VirtualBox is broken.
Sun, 22 Mar 2015 00:13:11 +0200 Ivan Klymenko написав: > After auditing the r280312 I just upgraded to revision r280332 and > then discovered that my VirtualBox is broken. > > Thanks. The problem was to use the port security/openssl. 1. Added WITH_OPENSSL_BASE=yes > /etc/make.conf 2. Delete installed security/openssl 3. Rebuild VirtualBox and others depends ports ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Bazaaring the cathedral (Lowering the Barrier to Entry)
On 04/01/15 18:55, Eitan Adler wrote: One of the key reasons for the lack of people is the high barrier of entry to joining the FreeBSD project. While every modern project uses git (usually hosted on github), FreeBSD uses self-hosted subversion. The use of git goes beyond just the choice of version control. It allows for workflows that FreeBSD can't even dream of. The linux kernel has no concept of a committer. Instead anyone can clone the git tree, build a kernel, and call themselves a Linux distribution. Hi Eitan, Before you speak so nicely about how Linux is doing things, have you ever tried to submit a patch to Linux yourself? I have a bunch of candidates in /usr/ports/multimedia/webcamd/work/webcamd-3.18.0.1/patches (Use this latest tarball: http://home.selasky.org:8192/distfiles/webcamd-4.0.0.2.tar.bz2) which you can start with as a fun experiment ! And then write back when your done. I'm starting counting right now. I have ported a lot of Linux USB drivers to userspace in FreeBSD through the webcamd project, and quite frequently I need to make patches to make the code compile which really should be up-streamed. Sometimes I also find real bugs. Sending the patch to Linux-USB is easy. Getting attention to the patch is hard. Frequent roadblocks in the Linux-USB: - patch must be styled correctly - patch must be send using a certain e-mail program - patch must apply cleanly to the Linux GIT - patch must have a signed-off-by before it can be committed Speaking about USB I don't want FreeBSD-USB to become what Linux-USB is. There are so many mails flowing into Linux-USB every day that no-one is caring to read it all. Getting a decent reply from someone can take months, because of the huge amount of e-mails. --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Bazaaring the cathedral (Lowering the Barrier to Entry)
On Wed, 1 Apr 2015, Eitan Adler wrote: > Hi all, > > One of the key reasons for the lack of people is the high barrier of > entry to joining the FreeBSD project. While every modern project uses > git (usually hosted on github), As much as I love github - please try to go to http://github.com/freebsd/freebsd-ports and try to view history of one particular port. Example task I am facing right now: "I need to compile iojs 1.0.4 using older version of FreeBSD port". Github web interface says to me: > > Sorry, this commit history is taking too long to generate. > > Refresh the page to try again, or view this history locally using the > > following command: > > git log master -- www/iojs/Makefile Sure one might argue every ports should be a separate repository and we should use git submodules. No, thank you. > Our wiki and code review tools are in an even worse position than our > repository. In order to contribute you need to send an email to > clusteradm@ and hope they deem you worthy enough of access. The bug > tracking system is in a better shape but isn't perfect: while any user > can create an account, their privileges are limited: they can't help > close out bad PRs, reclassify good ones, or do other generally useful > work. I am pretty frustrated I can't login to Phabricator without @freebsd.org address. This is something that should be addressed _ReallySoonNow_ I don't follow FreeBSD intrastructure discussions but I don't understand while we jumed from gnats onto bugzilla instead of going straight to Phabricator Maniphest. Also from my Phabricator experience it is still a bit better suited for svn-centralized model than git (although it supports git as well). > Today I hope we turn ourselves from the cathedral into a truly open > and democratic project! I'd love to have a Phabricator account but despite using FreeBSD since I think version 2.1 and contributing very little I never aspired to get a commit bit. //Marcin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Bazaaring the cathedral (Lowering the Barrier to Entry)
I hope this is not one more of those April fools :-) --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FYI: 11.0-CURRENT's contrib/ntp -r280915, some boot-time ntpd error messages
On 2015-Apr-1, at 08:12 PM, Kevin Oberman wrote: > > On Wed, Apr 1, 2015 at 12:08 PM, Mark Millard wrote: > I rebuilt and the boot-message line > > > Mar 31 17:20:08 FBSDG5C0 ntpd[775]: line 22 column 1 syntax error > > > is no longer is occurring. But I'm still getting the other two: > > > Mar 31 17:20:08 FBSDG5C0 ntpd[775]: setsockopt IPV6_MULTICAST_IF 0 for > > [omitted] fails: Can't assign requested address > > Mar 31 17:20:08 FBSDG5C0 ntpd[775]: setsockopt IPV6_MULTICAST_IF 0 for > > [omitted] fails: Can't assign requested address > > > === > Mark Millard > markmi at dsl-only.net > > This is probably way too obvious, but is the system configured for IPv6? > -- > Kevin Oberman, Network Engineer, Retired > E-mail: rkober...@gmail.com > I do not know how much the two messages matter --for me or to anyone else. They might not be interesting other than my being educated a bit. As for what all is non-default for my configuration files (not much)... My use of networking is minimal and the configuration changes for that are limited to rc.conf: > # more /etc/rc.conf > hostname="FBSDG5C0" > ifconfig_bge0="DHCP" > ifconfig_bge0_ipv6="inet6 accept_rtadv" > ifconfig_gem0="DHCP" > ifconfig_gem0_ipv6="inet6 accept_rtadv" > sshd_enable="YES" > ntpd_enable="YES" > ntpd_sync_on_start="YES" > # Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable > dumpdev="AUTO" > hald_enable="YES" > dbus_enable="YES" Historically I've used 10.1-STABLE that way and still do. Recently I've been experimenting with 11.0-CURRENT based on the same sort of /etc/rc.conf file. I'm not getting the notices for 10.1-STABLE and have not been. I am getting the notices for 11.0-CURRENT now but I did not notice such with the few earlier-vintage builds that I've done. It is possible that I just did not notice: I do not have much 11.0-CURRENT history. If so, then my notes are more of a 10.1-STABLE vs. 11.0-CURRENT difference notice. I also fiddle with /boot/loader.conf, /etc/fstab, /etc/make.conf, and /etc/src.conf primarily. /etc/sysctl.conf for dump issues. /usr/local/etc/sudoers . The rest of the configuration files are at the default/installation status. The PowerMac that I plug the SSD into at the time determines which of bge0 vs. gem0 actually exists. === Mark Millard markmi at dsl-only.net ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Bazaaring the cathedral (Lowering the Barrier to Entry)
El 02/04/2015 11:03, "Hans Petter Selasky" escribió: > > On 04/01/15 18:55, Eitan Adler wrote: >> >> One of the key reasons for the lack of people is the high barrier of >> entry to joining the FreeBSD project. While every modern project uses >> git (usually hosted on github), FreeBSD uses self-hosted subversion. >> The use of git goes beyond just the choice of version control. It >> allows for workflows that FreeBSD can't even dream of. The linux >> kernel has no concept of a committer. Instead anyone can clone the >> git tree, build a kernel, and call themselves a Linux distribution. > > > Hi Eitan, > > Before you speak so nicely about how Linux is doing things, have you ever tried to submit a patch to Linux yourself? I have a bunch of candidates in /usr/ports/multimedia/webcamd/work/webcamd-3.18.0.1/patches (Use this latest tarball: http://home.selasky.org:8192/distfiles/webcamd-4.0.0.2.tar.bz2) which you can start with as a fun experiment ! And then write back when your done. I'm starting counting right now. > > I have ported a lot of Linux USB drivers to userspace in FreeBSD through the webcamd project, and quite frequently I need to make patches to make the code compile which really should be up-streamed. Sometimes I also find real bugs. Sending the patch to Linux-USB is easy. Getting attention to the patch is hard. Frequent roadblocks in the Linux-USB: > - patch must be styled correctly > - patch must be send using a certain e-mail program > - patch must apply cleanly to the Linux GIT > - patch must have a signed-off-by before it can be committed > I suppose no project is perfect, but all of the above make sense to me. The only thing I disagree is about the mail client. I've never seen that restriction in the documents in the documentation directory of the kernel. I've read restrictions about the format of the mails though. > Speaking about USB I don't want FreeBSD-USB to become what Linux-USB is. There are so many mails flowing into Linux-USB every day that no-one is caring to read it all. Getting a decent reply from someone can take months, because of the huge amount of e-mails. > Getting attention to the patch being hard is probably because of the amount of patches sent every day, but with a fairly smaller stream of patches in FreeBSD, we have some of them sitting in bugzilla for a really long time. Cheers. > --HPS > > > > > ___ > freebsd-hack...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ntpd errors after upgrade on current amd64
FWIW, I’m seeing the same thing. — Joel > 1 apr 2015 kl. 17:32 skrev Manfred Antar : > > After build install world on current ntpd doesn't work. > Here is error: > > FreeBSD/amd64 (pozo.com) (ttyu0) > > login: Apr 1 08:29:19 pozo ntpd[49825]: line 22 column 1 syntax error > Apr 1 08:29:19 pozo ntpd[49825]: setsockopt IPV6_MULTICAST_IF 0 for > fe80::1%2 fails: Can't assign requested address > > I'm using the stock ntp.conf from /usr/src/etc. > It worked fine before the upgrade > Thanks ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Bazaaring the cathedral (Lowering the Barrier to Entry)
Hans Petter Selasky wrote: > I hope this is not one more of those April fools :-) I've been thinking that since Eitan's first post of Wed, 1 Apr 2015 09:55:11 -0700 (18:55 CEST) "self-serve commit access" I kept wondering what would keep looneys out ? :-) Your experience feeding back to Linux was interesting, I suppose we assume "the grass is greener" till we hear someone tried it :-) Fernando, Your mailer software auto fold mechanism is bad, best turn it off. It corrupted quote from Hans Petter. It inserted repeated "\n" not "\n> " Cheers, Julian -- Julian Stacey, BSD Linux Unix C Sys Eng Consultant Munich http://berklix.com Indent previous with "> ". Reply Below as a play script. Send plain text, Not quoted-printable, HTML, or base64. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] Call for testing pkg 1.5.0
On Tue, 31 Mar 2015 21:03:23 +0200 Baptiste Daroussin wrote > Hi all, > > We just released pkg 1.5.0 beta1 (in ports-mgmt/pkg-devel), > .. > Please test and report as much bugs as you can! > We could be very grateful if regressions tests could be provided along with > the bug reports :) > > Plan is to release 1.5.0 as soon as possible > > Best regards, > Bapt Hello, Baptiste. I just wanted to take the time to thank you for all the work you've put into this. Thanks! --Chris ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Last week to submit FreeBSD 2015Q1 (January-March) Status Reports
Dear FreeBSD Community, The first quarter of 2015 has come and passed, and the deadline for the FreeBSD Quarterly Status Report for the first quarter is fast approaching -- the deadline is April 7, 2015, for work done in January through March. Status report submissions do not have to be very long. They may be about anything happening in the FreeBSD project and community, and provide a great way to inform FreeBSD users and developers about what you're working on. Submission of reports is not restricted to committers. Anyone doing anything interesting and FreeBSD-related can -- and should -- write one! The preferred and easiest submission method is to use the XML generator [1] with the results emailed to the status report team at monthly at freebsd.org . There is also an XML template [2] which can be filled in manually and attached if preferred. For the expected content and style, please study our guidelines on how to write a good status report [3]. You can also review previous issues [4,5] for ideas on the style and format. We are looking forward to all of your 2015Q1 reports! Thanks, Ben (on behalf of monthly@) [1] http://www.freebsd.org/cgi/monthly.cgi [2] http://www.freebsd.org/news/status/report-sample.xml [3] http://www.freebsd.org/news/status/howto.html [4] http://www.freebsd.org/news/status/report-2014-07-2014-09.html [5] http://www.freebsd.org/news/status/report-2014-10-2014-12.html ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Bazaaring the cathedral (Lowering the Barrier to Entry)
Eitan, This being posted on April 1 sets off my BS-o-meter, but I'll bite since it's a topic worth shaving a yak or two over. WARNING: there be perceptions and opinions here Having been ephemerally associated with FreeBSD since early 4.x, I never really saw FreeBSD as being cathedral-like, but the barrier to entry today feels even higher than it did 15 years ago. I view FreeBSD as being very much bazaar-like in terms of the actual code that comprises the OS and how it's treated, but like I must reiterate: the wall is harder to scale today. I appreciate the work that everyone has done over the years to bring the project's infrastructure up to modern times, such as the work done bringing in CI, a modern bug tracker and an honest to goodness code review tool, but the general workflow that I learned all those years ago for getting a change to go live *feels* more or less still the same: - find/fix bug - send-pr (okay... but you get the idea) - pester a committer with the proper access - ??? - profit!!! The arbitrary nature of how commit bits have historically been allocated have been more of a detractor than anything, making the the barrier appear even higher than it may actually be. The general wisdom I learned was "when you've bugged people often enough to commit your code, they'll burden you with that ability", which is great in terms of a pure meritocracy, but we're people and things aren't so black and white. Commit access thresholds shouldn't be measured in SLOC. Yes, the meritocratic way of handling commit access has worked well enough so far, but it has been at a cost (see FreeBSD's standing in the mindshare/overall market, as well as number of active FreeBSD committers vs your favorite big name Linux flavor). Access to the tools that the project has gravitated towards can be difficult if not impossible to obtain without a long slog through commit hell to get that sweet @FreeBSD.org spiff. Is a "free commit access for anyone!" approach really the answer? It feels like going from one extreme to the other, and we all know how extremes work. I feel that commit access should be more transparent, so that if someone really wants to be able to push code or act as a representative of the project, they can learn how to work towards that, instead of some nebulous "push enough code until we get tired of committing it". Again, I'm pretty sure this is just a April 1 troll, but it's all worth saying since the topic was brought up. Lowering the barrier to entry is good, but the act of doing so mustn't come at a detriment to quality. -Samuel On Wed, Apr 1, 2015 at 9:55 AM, Eitan Adler wrote: > Hi all, > > FreeBSD today has a significant problem of attracting new developers. > The lack of new developers manifests itself in a dearth of driver > support, inadequate documentation, and trailing third party packages. > > One of the key reasons for the lack of people is the high barrier of > entry to joining the FreeBSD project. While every modern project uses > git (usually hosted on github), FreeBSD uses self-hosted subversion. > The use of git goes beyond just the choice of version control. It > allows for workflows that FreeBSD can't even dream of. The linux > kernel has no concept of a committer. Instead anyone can clone the > git tree, build a kernel, and call themselves a Linux distribution. > > Our wiki and code review tools are in an even worse position than our > repository. In order to contribute you need to send an email to > clusteradm@ and hope they deem you worthy enough of access. The bug > tracking system is in a better shape but isn't perfect: while any user > can create an account, their privileges are limited: they can't help > close out bad PRs, reclassify good ones, or do other generally useful > work. > > To solve this problem I propose a simple solution: self-serve commit > access. We create a web service on accounts.freebsd.org via which > users can create themselves a freefall account. In addition to a > freefall account, the identical username would be created for the wiki > and phabricator, bugzilla, and any other service we might provide. > > This will allow us to quickly gain large number of contributors, who > will be able to make better progress on our missing features, and > rectify some of the drawbacks listed above. > > Today I hope we turn ourselves from the cathedral into a truly open > and democratic project! > > > -- > Eitan Adler > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Bazaaring the cathedral (Lowering the Barrier to Entry)
Joke or not, it's worth pointing out that while DragonFlyBSD's approach seems to be a fairly sane hybrid; there is no reason this can't be done within FreeBSD right now. https://www.dragonflybsd.org/docs/developer/TypicalGitUsage/ Anyone can clone, but if you can't commit to the repo then you're asked to register at http://bugs.dragonflybsd.org/ and send your patch over email. DFBSD's GItub repo is just a mirror and FreeBSD has something similar available, including a "GitWorkFlow" document: https://wiki.freebsd.org/GitWorkflow So I don't see why *now* someone couldn't basically follow the same workflow if they wanted to contribute to FreeBSD; namely: * clone mirrored repo/branch from GH * make changes * create a problem report at bugs.freebsd.org * submit patches And if this is not possible, it is likely a procedural impediment and not a technical one. Cheers, Brett On Thu, Apr 2, 2015 at 10:20 AM, Samuel Cassiba wrote: > Eitan, > > This being posted on April 1 sets off my BS-o-meter, but I'll bite since > it's a topic worth shaving a yak or two over. > > WARNING: there be perceptions and opinions here > > Having been ephemerally associated with FreeBSD since early 4.x, I never > really saw FreeBSD as being cathedral-like, but the barrier to entry today > feels even higher than it did 15 years ago. I view FreeBSD as being very > much bazaar-like in terms of the actual code that comprises the OS and how > it's treated, but like I must reiterate: the wall is harder to scale today. > > I appreciate the work that everyone has done over the years to bring the > project's infrastructure up to modern times, such as the work done bringing > in CI, a modern bug tracker and an honest to goodness code review tool, but > the general workflow that I learned all those years ago for getting a > change to go live *feels* more or less still the same: > - find/fix bug > - send-pr (okay... but you get the idea) > - pester a committer with the proper access > - ??? > - profit!!! > > The arbitrary nature of how commit bits have historically been allocated > have been more of a detractor than anything, making the the barrier appear > even higher than it may actually be. The general wisdom I learned was "when > you've bugged people often enough to commit your code, they'll burden you > with that ability", which is great in terms of a pure meritocracy, but > we're people and things aren't so black and white. Commit access thresholds > shouldn't be measured in SLOC. > > Yes, the meritocratic way of handling commit access has worked well enough > so far, but it has been at a cost (see FreeBSD's standing in the > mindshare/overall market, as well as number of active FreeBSD committers vs > your favorite big name Linux flavor). Access to the tools that the project > has gravitated towards can be difficult if not impossible to obtain without > a long slog through commit hell to get that sweet @FreeBSD.org spiff. > > Is a "free commit access for anyone!" approach really the answer? It feels > like going from one extreme to the other, and we all know how extremes > work. I feel that commit access should be more transparent, so that if > someone really wants to be able to push code or act as a representative of > the project, they can learn how to work towards that, instead of some > nebulous "push enough code until we get tired of committing it". > > Again, I'm pretty sure this is just a April 1 troll, but it's all worth > saying since the topic was brought up. Lowering the barrier to entry is > good, but the act of doing so mustn't come at a detriment to quality. > > > -Samuel > > On Wed, Apr 1, 2015 at 9:55 AM, Eitan Adler wrote: > > > Hi all, > > > > FreeBSD today has a significant problem of attracting new developers. > > The lack of new developers manifests itself in a dearth of driver > > support, inadequate documentation, and trailing third party packages. > > > > One of the key reasons for the lack of people is the high barrier of > > entry to joining the FreeBSD project. While every modern project uses > > git (usually hosted on github), FreeBSD uses self-hosted subversion. > > The use of git goes beyond just the choice of version control. It > > allows for workflows that FreeBSD can't even dream of. The linux > > kernel has no concept of a committer. Instead anyone can clone the > > git tree, build a kernel, and call themselves a Linux distribution. > > > > Our wiki and code review tools are in an even worse position than our > > repository. In order to contribute you need to send an email to > > clusteradm@ and hope they deem you worthy enough of access. The bug > > tracking system is in a better shape but isn't perfect: while any user > > can create an account, their privileges are limited: they can't help > > close out bad PRs, reclassify good ones, or do other generally useful > > work. > > > > To solve this problem I propose a simple solution: self-serve commit > > access. We create a web service on acc
Re: Bazaaring the cathedral (Lowering the Barrier to Entry)
On Thu, 2 Apr 2015 08:20:57 -0700 Samuel Cassiba wrote > Eitan, > > This being posted on April 1 sets off my BS-o-meter, but I'll bite since > it's a topic worth shaving a yak or two over. > > WARNING: there be perceptions and opinions here > > Having been ephemerally associated with FreeBSD since early 4.x, I never .. > Again, I'm pretty sure this is just a April 1 troll, but it's all worth > saying since the topic was brought up. Lowering the barrier to entry is > good, but the act of doing so mustn't come at a detriment to quality. OK. I'll bite... IMHO I believe that the height of the bar, is directly proportionate to the quality of the product. --Chris > > > -Samuel > > On Wed, Apr 1, 2015 at 9:55 AM, Eitan Adler wrote: > > > Hi all, > > > > FreeBSD today has a significant problem of attracting new developers. > > The lack of new developers manifests itself in a dearth of driver > > support, inadequate documentation, and trailing third party packages. > > > > One of the key reasons for the lack of people is the high barrier of > > entry to joining the FreeBSD project. While every modern project uses > > git (usually hosted on github), FreeBSD uses self-hosted subversion. > > The use of git goes beyond just the choice of version control. It > > allows for workflows that FreeBSD can't even dream of. The linux > > kernel has no concept of a committer. Instead anyone can clone the > > git tree, build a kernel, and call themselves a Linux distribution. > > > > Our wiki and code review tools are in an even worse position than our > > repository. In order to contribute you need to send an email to > > clusteradm@ and hope they deem you worthy enough of access. The bug > > tracking system is in a better shape but isn't perfect: while any user > > can create an account, their privileges are limited: they can't help > > close out bad PRs, reclassify good ones, or do other generally useful > > work. > > > > To solve this problem I propose a simple solution: self-serve commit > > access. We create a web service on accounts.freebsd.org via which > > users can create themselves a freefall account. In addition to a > > freefall account, the identical username would be created for the wiki > > and phabricator, bugzilla, and any other service we might provide. > > > > This will allow us to quickly gain large number of contributors, who > > will be able to make better progress on our missing features, and > > rectify some of the drawbacks listed above. > > > > Today I hope we turn ourselves from the cathedral into a truly open > > and democratic project! > > > > > > -- > > Eitan Adler > > ___ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > > > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] Call for testing pkg 1.5.0
On Thu, Apr 02, 2015 at 07:21:19AM -0700, Chris H wrote: > On Tue, 31 Mar 2015 21:03:23 +0200 Baptiste Daroussin wrote > > > Hi all, > > > > We just released pkg 1.5.0 beta1 (in ports-mgmt/pkg-devel), > > > .. > > Please test and report as much bugs as you can! > > We could be very grateful if regressions tests could be provided along with > > the bug reports :) > > > > Plan is to release 1.5.0 as soon as possible > > > > Best regards, > > Bapt > Hello, Baptiste. > I just wanted to take the time to thank you for all the > work you've put into this. > > Thanks! Thanks much appreciated, I want to share that with vsevolod@ and az@ who also spent a lot of time working on it! Best regards, Bapt pgpwXsh20z9bv.pgp Description: PGP signature
Re: ntpd errors after upgrade on current amd64
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 04/01/2015 11:32, Manfred Antar wrote:
> After build install world on current ntpd doesn't work. Here is
> error:
>
> FreeBSD/amd64 (pozo.com) (ttyu0)
>
> login: Apr 1 08:29:19 pozo ntpd[49825]: line 22 column 1 syntax
> error
ntp_crypto.c was not properly merged. Basically, the fix for
SA-14:31.ntp was applied twice. Please try the attached patch.
> Apr 1 08:29:19 pozo ntpd[49825]: setsockopt IPV6_MULTICAST_IF 0
> for fe80::1%2 fails: Can't assign requested address
A separate issue, I think.
Jung-uk Kim
* Note: ntp_parser.y is redundant and it was the root cause of
inconsistent builds and build failures, i.e., ntp_parser.c and
ntp_parser.h may be regenerated on the *source* directory depending on
phase of the moon. Although we can re-gen them after r280915,
upstream does not support BSD yacc.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQEcBAEBCAAGBQJVHaJXAAoJEHyflib82/FGla0H/i7cQunatuUUhGYPGGenmy1X
DEo7zL/LYNWX7XY392dIDKFGZguvErehVy7KNiVXZzrlsz0JRVpQp/r8OT6xPrFF
lGFaOgGB9tfIYKZl+Bn2gE40mwtfp7UX3B2nIswwF2SFBhyuJPiIZ5Y+j3YDyIHS
/BGUs0D+CaKq9RgU66QrowMOtA/uElWix44VHVSNJ2knAL+x6cZF4VzNTC+6wG2c
DVODrTMSqMAwiIkPYJCndbxH7C9ZaQEHVq19pTmYRb1V7x2VO0/3NrBJJYSP9GGe
PQS/HiU9lkIi/JSj3AN9+ntyzKpne/DJz6/AAe/JpCGj/o1Ke+ageA6m7yoqHL8=
=wNw9
-END PGP SIGNATURE-
Index: contrib/ntp/ntpd/ntp_crypto.c
===
--- contrib/ntp/ntpd/ntp_crypto.c (revision 280991)
+++ contrib/ntp/ntpd/ntp_crypto.c (working copy)
@@ -826,10 +826,10 @@ crypto_recv(
* Decrypt the cookie, hunting all the time for
* errors.
*/
- if (vallen == (u_int) EVP_PKEY_size(host_pkey)) {
+ if (vallen == (u_int)EVP_PKEY_size(host_pkey)) {
u_int32 *cookiebuf = malloc(
RSA_size(host_pkey->pkey.rsa));
-if (cookiebuf == NULL) {
+if (!cookiebuf) {
rval = XEVNT_CKY;
break;
}
@@ -3817,7 +3817,7 @@ crypto_setup(void)
randfile);
exit (-1);
}
- get_systime(&seed);
+ arc4random_buf(&seed, sizeof(l_fp));
RAND_seed(&seed, sizeof(l_fp));
RAND_write_file(randfile);
#ifdef DEBUG
@@ -3850,36 +3850,6 @@ crypto_setup(void)
pinfo = crypto_key(filename, passwd, NULL);
if (pinfo == NULL) {
msyslog(LOG_ERR,
- "crypto_setup: random seed file not specified");
- exit (-1);
- }
- if ((bytes = RAND_load_file(rand_file, -1)) == 0) {
- msyslog(LOG_ERR,
- "crypto_setup: random seed file %s not found\n",
- rand_file);
- exit (-1);
- }
- arc4random_buf(&seed, sizeof(l_fp));
- RAND_seed(&seed, sizeof(l_fp));
- RAND_write_file(rand_file);
- OpenSSL_add_all_algorithms();
-#ifdef DEBUG
- if (debug)
- printf(
- "crypto_setup: OpenSSL version %lx random seed file %s bytes read %d\n",
- SSLeay(), rand_file, bytes);
-#endif
-
- /*
- * Load required host key from file "ntpkey_host_". If
- * no host key file is not found or has invalid password, life
- * as we know it ends. The host key also becomes the default
- * sign key.
- */
- snprintf(filename, sizeof(filename), "ntpkey_host_%s", hostname);
- pinfo = crypto_key(filename, passwd, NULL);
- if (pinfo == NULL) {
- msyslog(LOG_ERR,
"crypto_setup: host key file %s not found or corrupt",
filename);
exit (-1);
Index: contrib/ntp/ntpd/ntp_parser.y
===
--- contrib/ntp/ntpd/ntp_parser.y (revision 280991)
+++ contrib/ntp/ntpd/ntp_parser.y (working copy)
@@ -1,1641 +0,0 @@
-/* ntp_parser.y
- *
- * The parser for the NTP configuration file.
- *
- * Written By: Sachin Kamboj
- * University of Delaware
- * Newark, DE 19711
- * Copyright (c) 2006
- */
-
-%parse-param { struct FILE_INFO *ip_file }
-%lex-param { struct FILE_INFO *ip_file }
-
-%{
- #ifdef HAVE_CONFIG_H
- # include
- #endif
-
- #include "ntp.h"
- #include "ntpd.h"
- #include "ntp_machine.h"
- #include "ntp_stdlib.h"
- #include "ntp_filegen.h"
- #include "ntp_scanner.h"
- #include "ntp_config.h"
- #include "ntp_crypto.h"
-
- #include "ntpsim.h" /* HMS: Do we really want this all the time? */
-/* SK: It might be a good idea to always
- include the simulator code. That way
- someone can use the same configuration file
- for both the simulator and the daemon
-*/
-
- #define YYMALLOC emalloc
- #define YYFREE free
- #define YYERROR_VERBOSE
- #define YYMAXDEPTH 1000 /* stop the madness sooner */
- void yyerror(struct FILE_INFO *ip_file, const char *msg);
-
- #ifdef SIM
- # define ONLY_SIM(a) (a)
- #else
- # define ONLY_SIM(a) NULL
- #endif
-%}
-
-/*
- * Enable generation of token names array even without YYDEBUG.
- * We access via token_name() defined below.
- */
-%token-table
-
-%union {
- char * String;
- double Double;
- int Integer;
- unsigned U_int;
- gen_fifo * Generic_fifo;
- attr_val * Attr_val;
- attr_val_fifo * Attr_val_fifo;
- int_fifo * Int_fifo;
- string_fifo * String_fifo;
- address_node * Add
Re: Bazaaring the cathedral (Lowering the Barrier to Entry)
On Apr 2, 2015 9:44 AM, "Chris H" wrote: > > IMHO I believe that the height of the bar, is directly proportionate > to the quality of the product. We were all new once. There are many reasons - language, social fluidity, economic background, etc. - for which a too-high initial hurdle can make a high bar so insurmountable as to prevent valuable contributors from getting in at all. Mentorship needs to take this into account. The trick is maintaining quality control at higher volumes, without quashing newbie enthusiasm. :) There are tools for managing this somewhat, but open source needs to grow more in this area. Royce ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ntpd errors after upgrade on current amd64
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 04/02/2015 16:11, Jung-uk Kim wrote:
> On 04/01/2015 11:32, Manfred Antar wrote:
>> Apr 1 08:29:19 pozo ntpd[49825]: setsockopt IPV6_MULTICAST_IF 0
>> for fe80::1%2 fails: Can't assign requested address
>
> A separate issue, I think.
This issue will be fixed in the next release, it seems.
http://lists.ntp.org/pipermail/bk-ntp-stable-send/2015-March/000594.html
Please try the updated patch. It fixed the problem for me. Note this
patch supersedes the previous patch.
Jung-uk Kim
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQEcBAEBCAAGBQJVHbTRAAoJEHyflib82/FGPP0H/iZpzPxGokR1CD16K4i/dH/F
qSfefNpW20dnl3ozIv3P0e1yC/xxMUJJNF4HQ8fwjr1bTI3efZ8gTPR2Zk3k5r7i
2OcQfrQma3cSkzoks6tjobor/yGpQEHJkwFwSSEsUKgA/rI0FpvviHQsQOi/6BnA
KbWQWLt5ZTe/V/27Zc2AU38evJxRFiYiJTycutQzMZ1NHle8DWqQ7vMKOe+CilAW
MX/16AW2tp2yrBs9XQKmkh0Yd2dTLJuBxAV7Rl8cVUZgdELqyE2FNSEL7L7TKKbs
QjJj6+7oee/c22Fc11CA7fBRFkK6m8fzmL/2CuTvf0JLefisCvMMcymvxH/edoM=
=UPrE
-END PGP SIGNATURE-
Index: contrib/ntp/lib/isc/unix/ifiter_getifaddrs.c
===
--- contrib/ntp/lib/isc/unix/ifiter_getifaddrs.c (revision 281003)
+++ contrib/ntp/lib/isc/unix/ifiter_getifaddrs.c (working copy)
@@ -212,6 +212,9 @@ internal_current(isc_interfaceiter_t *iter) {
get_addr(family, &iter->current.broadcast, ifa->ifa_broadaddr,
ifa->ifa_name);
+#ifdef ISC_PLATFORM_HAVEIFNAMETOINDEX
+ iter->current.ifindex = if_nametoindex(iter->current.name);
+#endif
return (ISC_R_SUCCESS);
}
Index: contrib/ntp/lib/isc/unix/ifiter_ioctl.c
===
--- contrib/ntp/lib/isc/unix/ifiter_ioctl.c (revision 281003)
+++ contrib/ntp/lib/isc/unix/ifiter_ioctl.c (working copy)
@@ -588,6 +588,9 @@ internal_current4(isc_interfaceiter_t *iter) {
}
iter->current.netmask.type.in6.s6_addr[i] = (~0 << bits) & 0xff;
}
+#ifdef ISC_PLATFORM_HAVEIFNAMETOINDEX
+ iter->current.ifindex = if_nametoindex(iter->current.name);
+#endif
return (ISC_R_SUCCESS);
inet:
@@ -664,6 +667,9 @@ internal_current4(isc_interfaceiter_t *iter) {
}
get_addr(family, &iter->current.netmask,
(struct sockaddr *)&ifreq.ifr_addr, ifreq.ifr_name);
+#ifdef ISC_PLATFORM_HAVEIFNAMETOINDEX
+ iter->current.ifindex = if_nametoindex(iter->current.name);
+#endif
return (ISC_R_SUCCESS);
}
@@ -704,7 +710,6 @@ internal_current6(isc_interfaceiter_t *iter) {
get_addr(family, &iter->current.address,
(struct sockaddr *)&lifreq.lifr_addr, lifreq.lifr_name);
- iter->current.ifindex = lifreq.lifr_index;
if (isc_netaddr_islinklocal(&iter->current.address))
isc_netaddr_setzone(&iter->current.address,
(isc_uint32_t)lifreq.lifr_index);
@@ -844,7 +849,9 @@ internal_current6(isc_interfaceiter_t *iter) {
iter->current.netmask.type.in6.s6_addr[i / 8] =
(~0 << bits) & 0xff;
}
-
+#ifdef ISC_PLATFORM_HAVEIFNAMETOINDEX
+ iter->current.ifindex = if_nametoindex(iter->current.name);
+#endif
return (ISC_R_SUCCESS);
}
#endif
@@ -867,6 +874,9 @@ internal_current6(isc_interfaceiter_t *iter) {
get_addr(family, &iter->current.netmask,
(struct sockaddr *)&lifreq.lifr_addr, lifreq.lifr_name);
+#ifdef ISC_PLATFORM_HAVEIFNAMETOINDEX
+ iter->current.ifindex = if_nametoindex(iter->current.name);
+#endif
return (ISC_R_SUCCESS);
}
#endif
Index: contrib/ntp/ntpd/ntp_crypto.c
===
--- contrib/ntp/ntpd/ntp_crypto.c (revision 281003)
+++ contrib/ntp/ntpd/ntp_crypto.c (working copy)
@@ -826,10 +826,10 @@ crypto_recv(
* Decrypt the cookie, hunting all the time for
* errors.
*/
- if (vallen == (u_int) EVP_PKEY_size(host_pkey)) {
+ if (vallen == (u_int)EVP_PKEY_size(host_pkey)) {
u_int32 *cookiebuf = malloc(
RSA_size(host_pkey->pkey.rsa));
-if (cookiebuf == NULL) {
+if (!cookiebuf) {
rval = XEVNT_CKY;
break;
}
@@ -3817,7 +3817,7 @@ crypto_setup(void)
randfile);
exit (-1);
}
- get_systime(&seed);
+ arc4random_buf(&seed, sizeof(l_fp));
RAND_seed(&seed, sizeof(l_fp));
RAND_write_file(randfile);
#ifdef DEBUG
@@ -3850,36 +3850,6 @@ crypto_setup(void)
pinfo = crypto_key(filename, passwd, NULL);
if (pinfo == NULL) {
msyslog(LOG_ERR,
- "crypto_setup: random seed file not specified");
- exit (-1);
- }
- if ((bytes = RAND_load_file(rand_file, -1)) == 0) {
- msyslog(LOG_ERR,
- "crypto_setup: random seed file %s not found\n",
- rand_file);
- exit (-1);
- }
- arc4random_buf(&seed, sizeof(l_fp));
- RAND_seed(&seed, sizeof(l_fp));
- RAND_write_file(rand_file);
- OpenSSL_add_all_algorithms();
-#ifdef DEBUG
- if (debug)
- printf(
- "crypto_setup: OpenSSL version %lx random seed file %s bytes read %d\n",
- SSLeay(), rand_file, bytes);
-#endif
-
- /*
- * Load required host key from file "ntpkey_host_". If
- * no host key file is not found or has invalid password, life
-
Re: ntpd errors after upgrade on current amd64
In message <551da257.6060...@freebsd.org>, Jung-uk Kim writes: > This is a multi-part message in MIME format. > --090800070300040107060309 > Content-Type: text/plain; charset=utf-8 > Content-Transfer-Encoding: 8bit > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 04/01/2015 11:32, Manfred Antar wrote: > > After build install world on current ntpd doesn't work. Here is > > error: > > > > FreeBSD/amd64 (pozo.com) (ttyu0) > > > > login: Apr 1 08:29:19 pozo ntpd[49825]: line 22 column 1 syntax > > error > > ntp_crypto.c was not properly merged. Basically, the fix for > SA-14:31.ntp was applied twice. Please try the attached patch. > > > Apr 1 08:29:19 pozo ntpd[49825]: setsockopt IPV6_MULTICAST_IF 0 > > for fe80::1%2 fails: Can't assign requested address > > A separate issue, I think. > > Jung-uk Kim > > * Note: ntp_parser.y is redundant and it was the root cause of > inconsistent builds and build failures, i.e., ntp_parser.c and > ntp_parser.h may be regenerated on the *source* directory depending on > phase of the moon. Although we can re-gen them after r280915, > upstream does not support BSD yacc. Ntp_parser.y is not redundant. It is referenced by ntp_parser.c. I put that fix in two days ago. I'll re-merge based on your second patch/the posted fix. I'll try it first in the port though. -- Cheers, Cy Schubert or FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Bazaaring the cathedral (Lowering the Barrier to Entry)
On 4/2/15 6:53 AM, Julian H. Stacey wrote: Hans Petter Selasky wrote: I hope this is not one more of those April fools :-) I've been thinking that since Eitan's first post of Wed, 1 Apr 2015 09:55:11 -0700 (18:55 CEST) "self-serve commit access" I kept wondering what would keep looneys out ? :-) Your experience feeding back to Linux was interesting, I suppose we assume "the grass is greener" till we hear someone tried it :-) Agreed. Contributing to the git project itself was quite eye opening. They are very particular about the patch format and a few processes involved were very long. They also don't use github. That said, the community was pretty open to the patches (once I got the format correct) and it took about average amount of work to get my code submitted. -Alfred ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
