This patch updates www/opera and www/opera-linuxplugins to version 10.60. Changelog: http://www.opera.com/docs/changelogs/unix/1060/
Responsible Changed From-To: freebsd-ports-bugs->itetcu I'll take it.
State Changed From-To: open->feedback Leaving apart wrong plist and such, on my 8-STABLE-amd64 it crashes when I close it (even with vanilla ~/.opera). It also looses customizations of the interface; and at least for my 4 windows with many tabs, it freezes.
Let me know what's wrong with the plist. The other things mentioned are bugs in Opera, not in the port - they can't be fixed by changing the port. Feel free to file them as bugs at https://bugs.opera.com/wizard/. However, bugs that are found in Opera in your particular environment shouldn't stop others from receiving this update to their port.
Hi Arjan, > +share/applications/mimeinfo.cache This is generated file by update-desktop-database command run by Opera install script and shouldn't be included in pkg-plist. When you don't have desktop-file-utils package it does not created in the first place and leads to fail packaging. So, I think you would want to put: @unexec %%LOCALBASE%%/bin/update-desktop-database > /dev/null || /usr/bin/true to the last line of pkg-plist like some ports do. It looks to be The FreeBSD Way; 173 other ports do this. By the way, the install script explicitly prevents us installing on 9-CURRENT with case statement: | FreeBSD\ [78].*) This is not good, as FreeBSD 9 is designed to run older binary flawlessly (in the ideal world. :-) I hope that to be [7-9]. itetcu, I too have 10.60 dumping core at every exit on -CURRENT/amd64 too. Though, nice to hear this is not only a -CURRENT issue but also happened on 8-STABLE. -- kuro
Hi kuro, Thanks for the help. The attached patch (which replaces the previous patch) forces the install of Opera to make it possible to install the port on newer versions of FreeBSD as well (the port should check for the FreeBSD version, not the installer) and uses update-desktop-database. With regard to both your Operas crashing on exit: we have a bug report in our database that reports this happens in Opera for FreeBSD when using the GTK UI backend in desktop environments other than Gnome. You can try if this is the case by either running Opera in Gnome (if you are not right now), or by forcing the UI backend to pure X11 or KDE (by setting opera:config#FileSelector|DialogToolkit to 4 or 3, respectively). You can see which UI backend Opera uses by running 'opera --full-version'. Arjan -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Hi Arjan, Thanks for a tip and new patch. It install/package/deinstalls flawlessly on my 9-CURRENT/amd64 now. With | [File Selector] | Dialog Toolkit=4 running X11 toolkit it no longer crashes at exit. For me both =3 and =2, KDE4 and GTK2 crashes, perhaps because I don't run KDE4, or GNOME either. What an old-timer I am. The X11 is enough for me. Unlike previous versions, Opera now depends on outside supplied toolkit libraries such as libQtWhatever/libkXYZ or libgtk-something so this port should register dependencies on them (selectable through OPTIONS is nice.) And it might help to add an UPDATING entry, describing crash-at-exit issue with unfamiliar toolkits and workaround for it. By the way, it is truly incredible speed-up what the Opera 10.60 achieves to provide. No other web browsers required; I've lived with Opera and can't live without it any more. -- kuro
Op Sat, 10 Jul 2010 15:15:59 +0200 schreef <poyopoyo@puripuri.plala.or.jp>: > Hi Arjan, > > Thanks for a tip and new patch. It install/package/deinstalls > flawlessly on my 9-CURRENT/amd64 now. > > With > | [File Selector] > | Dialog Toolkit=4 > running X11 toolkit it no longer crashes at exit. For me both =3 and =2, > KDE4 and GTK2 crashes, perhaps because I don't run KDE4, or GNOME > either. What an old-timer I am. The X11 is enough for me. > > Unlike previous versions, Opera now depends on outside supplied > toolkit libraries such as libQtWhatever/libkXYZ or libgtk-something so > this > port should register dependencies on them (selectable through OPTIONS > is nice.) I thought about that, but it doesn't really depend on them. There's no preset choice on installation, Opera will autoselect a backend depending on your currently running desktop environment and available libraries. So it won't stop working if you deinstall all KDE and GTK libraries, for example, even if you are running KDE or GTK. And if you are running Opera in Gnome right now but later switch to KDE, Opera will load the KDE backend on startup. > And it might help to add an UPDATING entry, describing crash-at-exit > issue with unfamiliar toolkits and workaround for it. > > By the way, it is truly incredible speed-up what the Opera 10.60 > achieves to provide. No other web browsers required; I've lived with > Opera and can't live without it any more. Good to hear :) Arjan -- Gemaakt met Opera's revolutionaire e-mailprogramma: http://www.opera.com/mail/
Sat, 10 Jul 2010 20:56:44 +0200 Arjan van Leeuwen wrote: > I thought about that, but it doesn't really depend on them. There's no > preset choice on installation, Opera will autoselect a backend depending > on your currently running desktop environment and available libraries. So > it won't stop working if you deinstall all KDE and GTK libraries, for > example, even if you are running KDE or GTK. And if you are running Opera > in Gnome right now but later switch to KDE, Opera will load the KDE > backend on startup. I still think that at least the basic dependencies should be added: USE_XORG=x11 xext sm ice xft xrender LIB_DEPENDS= freetype.9:${PORTSDIR}/print/freetype2 \ fontconfig.1:${PORTSDIR}/x11-fonts/fontconfig Also optional dependencies for kde/qt backend would be good thing. p.s. Are You sure that 10.60 ready for prime time? I test it only for a few hours and already got a few nasty regressions. First - without qt opera can't parse /etc/printcap and as a result there is no printer. Workaround from 9.x with PrinterCustomName/PrinterCustomParameter also doesn't work. Second - weird problem with copy/paste. Some pages work ok(http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/148294) but from others paste don't work at all(http://google.com) -- Adios
On Mon, 12 Jul 2010 07:20:59 +0200, Alex Kozlov <spam@rm-rf.kiev.ua> wrote: > Sat, 10 Jul 2010 20:56:44 +0200 Arjan van Leeuwen wrote: > >> I thought about that, but it doesn't really depend on them. There's no >> preset choice on installation, Opera will autoselect a backend depending >> on your currently running desktop environment and available libraries. >> So >> it won't stop working if you deinstall all KDE and GTK libraries, for >> example, even if you are running KDE or GTK. And if you are running >> Opera >> in Gnome right now but later switch to KDE, Opera will load the KDE >> backend on startup. > I still think that at least the basic dependencies should be added: > USE_XORG=x11 xext sm ice xft xrender > > LIB_DEPENDS= freetype.9:${PORTSDIR}/print/freetype2 \ > fontconfig.1:${PORTSDIR}/x11-fonts/fontconfig You're right, it should have those. Added in the attached patch. As far as I can see that fulfills all the library requirements (ie. all the libraries Opera links to). > Also optional dependencies for kde/qt backend would be good thing. I'm still not convinced this is a good thing, because I'd say that a dependency means that something stops working when the dependency is removed. That is not the case here (even if you have a dependency on KDE, Opera will keep working fine if you remove it). Also the other way around: if you only select a dependency on KDE but later install GTK and run Gnome, it will use GTK and thus 'depend' on that (but nothing you can change in the port registration at that stage). > p.s. Are You sure that 10.60 ready for prime time? I test it only for a > few hours and > already got a few nasty regressions. 10.6 is a really big change from previous Opera Unix releases, so I would expect some bugs to be found. Of course this build has gone through extensive QA, but quite less so on FreeBSD compared to Linux, and there's also a lot less user testing on FreeBSD (ie. we get almost no bug reports for our weekly snapshots from FreeBSD users). The results of that would mostly be seen in configurations that are more 'custom' than others (not using well-known desktop environments etc). > First - without qt opera can't parse /etc/printcap and as a result there > is no printer. > Workaround from 9.x with PrinterCustomName/PrinterCustomParameter also > doesn't work. From 10.6 on, Opera needs Cups to do printing. I've updated the port to reflect that. Without Cups, you can only print to file. > Second - weird problem with copy/paste. Some pages work > ok(http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/148294) but from > others paste don't work at all(http://google.com) This is something that is better suited for entering into the bug system: https://bugs.opera.com/wizard/ Thanks, Arjan -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
On Mon, Jul 12, 2010 at 06:41:31PM +0200, Arjan van Leeuwen wrote: > On Mon, 12 Jul 2010 07:20:59 +0200, Alex Kozlov <spam@rm-rf.kiev.ua> wrote: > > Sat, 10 Jul 2010 20:56:44 +0200 Arjan van Leeuwen wrote: > > Also optional dependencies for kde/qt backend would be good thing. > I'm still not convinced this is a good thing, because I'd say that a > dependency means that something stops working when the dependency is > removed. That is not the case here (even if you have a dependency on KDE, > Opera will keep working fine if you remove it). Also the other way around: > if you only select a dependency on KDE but later install GTK and run > Gnome, it will use GTK and thus 'depend' on that (but nothing you can > change in the port registration at that stage). Keyword is optional. For example, they help in case when user want to try specific backend and dependencies for it not present. > > p.s. Are You sure that 10.60 ready for prime time? I test it only for a > > few hours and already got a few nasty regressions. > 10.6 is a really big change from previous Opera Unix releases, so I would > expect some bugs to be found. Of course this build has gone through > extensive QA, but quite less so on FreeBSD compared to Linux, and there's > also a lot less user testing on FreeBSD (ie. we get almost no bug reports > for our weekly snapshots from FreeBSD users). The results of that would > mostly be seen in configurations that are more 'custom' than others (not > using well-known desktop environments etc). Don't get me wrong, 10.6x have potential to be a great release, but as You say, it still rough and unpolished, so may be better to leave www/opera at 10.10 for now and commit this patch to www/opera-devel? > > First - without qt opera can't parse /etc/printcap and as a result there > > is no printer. > > Workaround from 9.x with PrinterCustomName/PrinterCustomParameter also > > doesn't work. > From 10.6 on, Opera needs Cups to do printing. I've updated the port to > reflect that. Without Cups, you can only print to file. It's strange decision, especially for bsd platform. But this can be easily solved by adding possibility to specify pipe instead of file. I.e. '|lpr' instead of /path/filename in Print to file. > > Second - weird problem with copy/paste. Some pages work > > ok(http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/148294) but from > > others paste don't work at all(http://google.com) > This is something that is better suited for entering into the bug system: > https://bugs.opera.com/wizard/ I will try latter. Also I have problem with fonts reseting to *Mono and many graphical glitches. -- Adios
Op Mon, 12 Jul 2010 20:26:14 +0200 schreef Alex Kozlov <spam@rm-rf.kiev.ua>: > On Mon, Jul 12, 2010 at 06:41:31PM +0200, Arjan van Leeuwen wrote: >> On Mon, 12 Jul 2010 07:20:59 +0200, Alex Kozlov <spam@rm-rf.kiev.ua> >> wrote: >> > Sat, 10 Jul 2010 20:56:44 +0200 Arjan van Leeuwen wrote: > >> > Also optional dependencies for kde/qt backend would be good thing. >> I'm still not convinced this is a good thing, because I'd say that a >> dependency means that something stops working when the dependency is >> removed. That is not the case here (even if you have a dependency on >> KDE, >> Opera will keep working fine if you remove it). Also the other way >> around: >> if you only select a dependency on KDE but later install GTK and run >> Gnome, it will use GTK and thus 'depend' on that (but nothing you can >> change in the port registration at that stage). > > Keyword is optional. For example, they help in case when user want to try > specific backend and dependencies for it not present. In that case I don't know enough about the FreeBSD ports system to make this decision, and would like to ask a FreeBSD ports committer to speak up. FWIW, on Debian we use the 'suggests' field for this. >> > p.s. Are You sure that 10.60 ready for prime time? I test it only for >> a >> > few hours and already got a few nasty regressions. >> 10.6 is a really big change from previous Opera Unix releases, so I >> would >> expect some bugs to be found. Of course this build has gone through >> extensive QA, but quite less so on FreeBSD compared to Linux, and >> there's >> also a lot less user testing on FreeBSD (ie. we get almost no bug >> reports >> for our weekly snapshots from FreeBSD users). The results of that would >> mostly be seen in configurations that are more 'custom' than others (not >> using well-known desktop environments etc). > > Don't get me wrong, 10.6x have potential to be a great release, but > as You say, it still rough and unpolished, so may be better to leave > www/opera at 10.10 for now and commit this patch to www/opera-devel? I didn't say it was rough and unpolished. Having it as opera-devel is not an option. Apart from being wrong (10.60 is the current final release, there are snapshots out that qualify as opera-devel) it puts users at risk - 10.60 also fixes security issues. Arjan -- Gemaakt met Opera's revolutionaire e-mailprogramma: http://www.opera.com/mail/
On Mon, Jul 12, 2010 at 10:24:56PM +0200, Arjan van Leeuwen wrote: > Op Mon, 12 Jul 2010 20:26:14 +0200 schreef Alex Kozlov wrote: > > On Mon, Jul 12, 2010 at 06:41:31PM +0200, Arjan van Leeuwen wrote: > >> On Mon, 12 Jul 2010 07:20:59 +0200, Alex Kozlov wrote: > >> > Sat, 10 Jul 2010 20:56:44 +0200 Arjan van Leeuwen wrote: > >> > Also optional dependencies for kde/qt backend would be good thing. > >> I'm still not convinced this is a good thing, because I'd say that a > >> dependency means that something stops working when the dependency is > >> removed. That is not the case here (even if you have a dependency on > >> KDE, Opera will keep working fine if you remove it). Also the other way > >> around: if you only select a dependency on KDE but later install GTK > >> and run Gnome, it will use GTK and thus 'depend' on that (but nothing > >> you can change in the port registration at that stage). > > Keyword is optional. For example, they help in case when user want to try > > specific backend and dependencies for it not present. > In that case I don't know enough about the FreeBSD ports system to > make this decision, and would like to ask a FreeBSD ports committer to > speak up. FWIW, on Debian we use the 'suggests' field for this. Something like this would be enough, I believe: OPTIONS= GTK "Use GTK backend" off \ QT "Use KDE backend" off .include <bsd.port.pre.mk> .ifdef WITH_GTK USE_GNOME= atk glib20 gtk20 pango USE_XORG+= xcomposite xcursor xdamage xfixes xi xinerama LIB_DEPENDS+= cairo.2:${PORTSDIR}/graphics/cairo .endif .ifdef WITH_KDE USE_KDE4= kdelibs USE_QT_VER= 4 QT_COMPONENTS= corelib gui .endif -- Adios
Op Tue, 13 Jul 2010 08:02:48 +0200 schreef Alex Kozlov <spam@rm-rf.kiev.ua>: > On Mon, Jul 12, 2010 at 10:24:56PM +0200, Arjan van Leeuwen wrote: >> Op Mon, 12 Jul 2010 20:26:14 +0200 schreef Alex Kozlov wrote: >> > On Mon, Jul 12, 2010 at 06:41:31PM +0200, Arjan van Leeuwen wrote: >> >> On Mon, 12 Jul 2010 07:20:59 +0200, Alex Kozlov wrote: >> >> > Sat, 10 Jul 2010 20:56:44 +0200 Arjan van Leeuwen wrote: > >> >> > Also optional dependencies for kde/qt backend would be good thing. >> >> I'm still not convinced this is a good thing, because I'd say that a >> >> dependency means that something stops working when the dependency is >> >> removed. That is not the case here (even if you have a dependency on >> >> KDE, Opera will keep working fine if you remove it). Also the other >> way >> >> around: if you only select a dependency on KDE but later install GTK >> >> and run Gnome, it will use GTK and thus 'depend' on that (but nothing >> >> you can change in the port registration at that stage). >> > Keyword is optional. For example, they help in case when user want to >> try >> > specific backend and dependencies for it not present. >> In that case I don't know enough about the FreeBSD ports system to >> make this decision, and would like to ask a FreeBSD ports committer to >> speak up. FWIW, on Debian we use the 'suggests' field for this. > Something like this would be enough, I believe: > > OPTIONS= GTK "Use GTK backend" off \ > QT "Use KDE backend" off > > .include <bsd.port.pre.mk> > > .ifdef WITH_GTK > USE_GNOME= atk glib20 gtk20 pango > USE_XORG+= xcomposite xcursor xdamage xfixes xi xinerama > LIB_DEPENDS+= cairo.2:${PORTSDIR}/graphics/cairo > .endif > > .ifdef WITH_KDE > USE_KDE4= kdelibs > USE_QT_VER= 4 > QT_COMPONENTS= corelib gui > .endif Yes, I understand how to do this. But I want to know whether it is the right thing to do from Ion-Mihai. Arjan -- Gemaakt met Opera's revolutionaire e-mailprogramma: http://www.opera.com/mail/
On Tue, 13 Jul 2010 09:40:14 +0200 "Arjan van Leeuwen" <arjanl@opera.com> wrote: > Op Tue, 13 Jul 2010 08:02:48 +0200 schreef Alex Kozlov > <spam@rm-rf.kiev.ua>: > > > On Mon, Jul 12, 2010 at 10:24:56PM +0200, Arjan van Leeuwen wrote: > >> Op Mon, 12 Jul 2010 20:26:14 +0200 schreef Alex Kozlov wrote: > >> > On Mon, Jul 12, 2010 at 06:41:31PM +0200, Arjan van Leeuwen wrote: > >> >> On Mon, 12 Jul 2010 07:20:59 +0200, Alex Kozlov wrote: > >> >> > Sat, 10 Jul 2010 20:56:44 +0200 Arjan van Leeuwen wrote: > > > >> >> > Also optional dependencies for kde/qt backend would be good thing. > >> >> I'm still not convinced this is a good thing, because I'd say that a > >> >> dependency means that something stops working when the dependency is > >> >> removed. That is not the case here (even if you have a dependency on > >> >> KDE, Opera will keep working fine if you remove it). Also the other > >> way > >> >> around: if you only select a dependency on KDE but later install GTK > >> >> and run Gnome, it will use GTK and thus 'depend' on that (but nothing > >> >> you can change in the port registration at that stage). > >> > Keyword is optional. For example, they help in case when user want to > >> try > >> > specific backend and dependencies for it not present. > >> In that case I don't know enough about the FreeBSD ports system to > >> make this decision, and would like to ask a FreeBSD ports committer to > >> speak up. FWIW, on Debian we use the 'suggests' field for this. > > Something like this would be enough, I believe: > > > > OPTIONS= GTK "Use GTK backend" off \ > > QT "Use KDE backend" off > > > > .include <bsd.port.pre.mk> > > > > .ifdef WITH_GTK > > USE_GNOME= atk glib20 gtk20 pango > > USE_XORG+= xcomposite xcursor xdamage xfixes xi xinerama > > LIB_DEPENDS+= cairo.2:${PORTSDIR}/graphics/cairo > > .endif > > > > .ifdef WITH_KDE > > USE_KDE4= kdelibs > > USE_QT_VER= 4 > > QT_COMPONENTS= corelib gui > > .endif > > Yes, I understand how to do this. But I want to know whether it is the > right thing to do from Ion-Mihai. I'm currrently in Brazil for a bit of relaxation and a talk at a conference. I asked miwi@ to handle this PR, since my internet access is very spotty and I'll return home only at the end of the month. -- Ion-Mihai Tetcu <ionut@tetcu.info>
Veniamin Gvozdikov---------------| OpenPGP ------------------------------------------- OpenPGP for this is e-mail adress| 9B9E5154 XMMP: zloidemon(at)jabber(dot)ru | 19B4A605
Hi Martin, can you help with this? See below: On Tue, 13 Jul 2010 11:12:00 +0200, Ion-Mihai Tetcu <ionut@tetcu.info> wrote: > On Tue, 13 Jul 2010 09:40:14 +0200 > "Arjan van Leeuwen" <arjanl@opera.com> wrote: > >> Op Tue, 13 Jul 2010 08:02:48 +0200 schreef Alex Kozlov >> <spam@rm-rf.kiev.ua>: >> >> > On Mon, Jul 12, 2010 at 10:24:56PM +0200, Arjan van Leeuwen wrote: >> >> Op Mon, 12 Jul 2010 20:26:14 +0200 schreef Alex Kozlov wrote: >> >> > On Mon, Jul 12, 2010 at 06:41:31PM +0200, Arjan van Leeuwen wrote: >> >> >> On Mon, 12 Jul 2010 07:20:59 +0200, Alex Kozlov wrote: >> >> >> > Sat, 10 Jul 2010 20:56:44 +0200 Arjan van Leeuwen wrote: >> > >> >> >> > Also optional dependencies for kde/qt backend would be good >> thing. >> >> >> I'm still not convinced this is a good thing, because I'd say >> that a >> >> >> dependency means that something stops working when the dependency >> is >> >> >> removed. That is not the case here (even if you have a dependency >> on >> >> >> KDE, Opera will keep working fine if you remove it). Also the >> other >> >> way >> >> >> around: if you only select a dependency on KDE but later install >> GTK >> >> >> and run Gnome, it will use GTK and thus 'depend' on that (but >> nothing >> >> >> you can change in the port registration at that stage). >> >> > Keyword is optional. For example, they help in case when user want >> to >> >> try >> >> > specific backend and dependencies for it not present. >> >> In that case I don't know enough about the FreeBSD ports system to >> >> make this decision, and would like to ask a FreeBSD ports committer >> to >> >> speak up. FWIW, on Debian we use the 'suggests' field for this. >> > >> > Something like this would be enough, I believe: >> > >> > OPTIONS= GTK "Use GTK backend" off \ >> > QT "Use KDE backend" off >> > >> > .include <bsd.port.pre.mk> >> > >> > .ifdef WITH_GTK >> > USE_GNOME= atk glib20 gtk20 pango >> > USE_XORG+= xcomposite xcursor xdamage xfixes xi xinerama >> > LIB_DEPENDS+= cairo.2:${PORTSDIR}/graphics/cairo >> > .endif >> > >> > .ifdef WITH_KDE >> > USE_KDE4= kdelibs >> > USE_QT_VER= 4 >> > QT_COMPONENTS= corelib gui >> > .endif >> >> Yes, I understand how to do this. But I want to know whether it is the >> right thing to do from Ion-Mihai. > > I'm currrently in Brazil for a bit of relaxation and a talk at a > conference. I asked miwi@ to handle this PR, since my internet access > is very spotty and I'll return home only at the end of the month. > > -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Responsible Changed From-To: itetcu->freebsd-ports-bugs release this PR. IMO this version is unusable, at least in my environment, so I won't commit it.
Responsible Changed From-To: freebsd-ports-bugs->dinoex I will take care of it.
dinoex 2010-08-13 12:21:17 UTC FreeBSD ports repository Modified files: www/opera Makefile distinfo pkg-plist www/opera/files operapluginwrapper patch-install.sh Log: - update to 10.61 PR: 148294 PR: 148818 Sumitted by: Arjan van Leeuwen Revision Changes Path 1.93 +71 -39 ports/www/opera/Makefile 1.62 +6 -12 ports/www/opera/distinfo 1.7 +0 -2 ports/www/opera/files/operapluginwrapper 1.28 +0 -19 ports/www/opera/files/patch-install.sh 1.39 +170 -25 ports/www/opera/pkg-plist _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
dinoex 2010-08-13 13:19:26 UTC FreeBSD ports repository Modified files: www/opera-linuxplugins Makefile distinfo Log: - update to 10.61 PR: 148294 PR: 148819 Submitted by: Arjan van Leeuwen Revision Changes Path 1.14 +8 -13 ports/www/opera-linuxplugins/Makefile 1.8 +3 -3 ports/www/opera-linuxplugins/distinfo _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
State Changed From-To: feedback->closed committed with small plist changes and 10.61 distribution, thanks.
dinoex 2010-08-14 04:11:59 UTC FreeBSD ports repository Removed files: www/opera/files patch-install.sh Log: - remove empty file Reported by: Matthew D. Fuller PR: 148294 Revision Changes Path 1.29 +0 -0 ports/www/opera/files/patch-install.sh (dead) _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"