INDEX build failed for 9.x
INDEX build failed with errors: Generating INDEX-9 - please wait..--- describe.accessibility --- --- describe.arabic --- --- describe.archivers --- --- describe.astro --- --- describe.audio --- --- describe.benchmarks --- --- describe.biology --- --- describe.cad --- --- describe.chinese --- --- describe.comms --- --- describe.converters --- --- describe.databases --- --- describe.deskutils --- --- describe.devel --- --- describe.dns --- --- describe.editors --- --- describe.emulators --- --- describe.finance --- --- describe.french --- --- describe.ftp --- [...] --- describe.print --- --- describe.russian --- --- describe.science --- --- describe.security --- --- describe.shells --- --- describe.sysutils --- --- describe.textproc --- --- describe.ukrainian --- --- describe.vietnamese --- --- describe.www --- --- describe.x11 --- --- describe.x11-clocks --- --- describe.x11-drivers --- --- describe.x11-fm --- --- describe.x11-fonts --- --- describe.x11-servers --- --- describe.x11-themes --- --- describe.x11-toolkits --- --- describe.x11-wm --- Done. make_index: /home/indexbuild/tindex/ports/textproc/py-snowballstemmer: no entry for /home/indexbuild/tindex/ports/textproc/py-pystemmer Committers on the hook: danfe kwm lwhsu robak Most recent SVN update was: Updating '.': Dtextproc/pystemmer Utextproc/py-sphinx/Makefile Atextproc/py-pystemmer Atextproc/py-pystemmer/Makefile Atextproc/py-pystemmer/distinfo Atextproc/py-pystemmer/pkg-descr Utextproc/py-snowballstemmer/Makefile UMOVED Adns/dnsdbck Adns/dnsdbck/Makefile Adns/dnsdbck/distinfo Adns/dnsdbck/pkg-descr Adns/renewck Adns/renewck/Makefile Adns/renewck/distinfo Adns/renewck/pkg-descr Udns/Makefile Uwww/webkit2-gtk3/Makefile Ugraphics/cairo/pkg-plist Ugraphics/cairo/Makefile Udevel/py-robotframework-pabot/distinfo Udevel/py-robotframework-pabot/Makefile Updated to revision 393640. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Telegram-cli Issues
Hello, The Telegram protocol and clients have a feature to shown to the sender when the receiver has read the message, Telegram Support calls this "read" status for messages and says it is an essential feature of Telegram. I call it a violation of the receivers privacy. I have an Ubuntu based mobile which has a Telegram app. We have had a long chat which can be seen here in issue tracker: https://bugs.launchpad.net/bugs/1475915 and both, Telegran Task Force and Canonical, are rejecting to make the read status report at least a configure value and any receiver can decide by its own to enable this or not. Related to this is as well the RFC 3798, which says: 6.2. Privacy Another dimension of security is privacy. There may be cases in which a message recipient does not wish the disposition of messages addressed to him to be known, or is concerned that the sending of MDNs may reveal other sensitive information (e.g., when the message was read). In this situation, it is acceptable for the MUA to issue "denied" MDNs or to silently ignore requests for MDNs. ... For the above mentioned reasons, I have de-installed the Telegram app on my mobile phone. Why I bring this up here? It would be nice, if we (FreeBSD) could add (as a patch in the ports tree) a configuration value to the telegram-cli which does not send such notifications when the configuration says so. What do you (all and Maintainer) think about? matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ ☎ +49-176-38902045 No! Nein! ¡No! Όχι! -- Ευχαριστούμε! ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Telegram-cli Issues
Hi! > The Telegram protocol and clients have a feature to shown to the sender > when the receiver has read the message, Telegram Support calls this > "read" status for messages and says it is an essential feature of > Telegram. > > I call it a violation of the receivers privacy. 100% agreed. > It would be nice, if we (FreeBSD) could add (as a patch in the ports > tree) a configuration value to the telegram-cli which does not > send such notifications when the configuration says so. > > What do you (all and Maintainer) think about? That would be very useful, yes. -- p...@opsec.eu+49 171 3101372 5 years to go ! ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
INDEX build failed for 9.x
INDEX build failed with errors: Generating INDEX-9 - please wait..--- describe.accessibility --- --- describe.arabic --- --- describe.archivers --- --- describe.astro --- --- describe.audio --- --- describe.benchmarks --- --- describe.biology --- --- describe.cad --- --- describe.chinese --- --- describe.comms --- --- describe.converters --- --- describe.databases --- --- describe.deskutils --- --- describe.devel --- --- describe.dns --- --- describe.editors --- --- describe.emulators --- --- describe.finance --- --- describe.french --- --- describe.ftp --- [...] --- describe.print --- --- describe.russian --- --- describe.science --- --- describe.security --- --- describe.shells --- --- describe.sysutils --- --- describe.textproc --- --- describe.ukrainian --- --- describe.vietnamese --- --- describe.www --- --- describe.x11 --- --- describe.x11-clocks --- --- describe.x11-drivers --- --- describe.x11-fm --- --- describe.x11-fonts --- --- describe.x11-servers --- --- describe.x11-themes --- --- describe.x11-toolkits --- --- describe.x11-wm --- Done. make_index: /home/indexbuild/tindex/ports/textproc/py-snowballstemmer: no entry for /home/indexbuild/tindex/ports/textproc/py-pystemmer Committers on the hook: amdmi3 ashish danfe kwm lwhsu marino robak tijl Most recent SVN update was: Updating '.': Umail/squirrelmail-calendar_file_backend-plugin/pkg-plist Umail/squirrelmail-change_ldappass-plugin/pkg-plist Udevel/automake/Makefile Udevel/autoconf/Makefile Udevel/gmake/Makefile Udevel/autoconf-wrapper/Makefile Udevel/gettext/Makefile.common Udevel/autoconf213/Makefile Udevel/autotools/Makefile Udevel/libtool/Makefile.common Udevel/jep/Makefile Udeskutils/virt-manager/Makefile Udns/Makefile Adns/axfr2acl Adns/axfr2acl/Makefile Adns/axfr2acl/distinfo Adns/axfr2acl/pkg-descr Udns/whoseip/Makefile Udns/whoseip/pkg-descr Adns/rpsl2acl Adns/rpsl2acl/Makefile Adns/rpsl2acl/distinfo Adns/rpsl2acl/pkg-descr Unet-im/ejabberd/pkg-plist Unet-im/ejabberd/Makefile Unet-im/ejabberd/distinfo Usecurity/kpcli/Makefile Usecurity/kpcli/distinfo Usecurity/Makefile Asecurity/p5-Crypt-PWSafe3 Asecurity/p5-Crypt-PWSafe3/distinfo Asecurity/p5-Crypt-PWSafe3/pkg-descr Asecurity/p5-Crypt-PWSafe3/pkg-plist Asecurity/p5-Crypt-PWSafe3/Makefile Udatabases/evolution-data-server/pkg-plist Udatabases/evolution-data-server/Makefile Updated to revision 393653. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Telegram-cli Issues
El día Thursday, August 06, 2015 a las 01:20:10PM +0200, Kurt Jaeger escribió:
> > It would be nice, if we (FreeBSD) could add (as a patch in the ports
> > tree) a configuration value to the telegram-cli which does not
> > send such notifications when the configuration says so.
> >
> > What do you (all and Maintainer) think about?
>
> That would be very useful, yes.
My ports tree on my netbook is from October 18, last year; I just
fetched the files for the port from svn and luckily they compile fine:
$ telegram-cli
Telegram-cli version 1.3.1, Copyright (C) 2013-2015 Vitaly Valtman
...
phone number: +49-176-38902045
code ('call' for phone call): 73469
User Matthias Apitz online (was online [2015/08/06 14:48:37])
> > All done. Exit
halt
I will see if I can open another account with some other mobile number I
own and send me messages from Telegam's web interface... to see and
debug how the sender gets informed when I receive a message. The cli
seems to have de debug output option..
matthias
--
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ ☎ +49-176-38902045
No! Nein! ¡No! Όχι! -- Ευχαριστούμε!
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Telegram-cli Issues
El día Thursday, August 06, 2015 a las 02:56:34PM +0200, Matthias Apitz
escribió:
> $ telegram-cli
> Telegram-cli version 1.3.1, Copyright (C) 2013-2015 Vitaly Valtman
> ...
> phone number: +49-176-38902045
> code ('call' for phone call): 73469
> User Matthias Apitz online (was online [2015/08/06 14:48:37])
> > > All done. Exit
> halt
The telegram-cli is NOT sending such read notifications. I installed
Telegram in my iPhone and when I do send from it messages they stay
with only one v (and not vv), even when I read the message with telegram-cli.
When I shutdown telegram-cli and start the Telegram app in my Ubuntu
mobile BQ E4.5, magically all old messages in the iPhone get the second
marker v, ie have now marked vv.
This is good news.
matthias
--
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ ☎ +49-176-38902045
No! Nein! ¡No! Όχι! -- Ευχαριστούμε!
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
INDEX now builds successfully on 9.x
___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Telegram-cli Issues
El jue, 06-08-2015 a las 13:20 +0200, Kurt Jaeger escribió: > Hi! > > > The Telegram protocol and clients have a feature to shown to the > > sender > > when the receiver has read the message, Telegram Support calls this > > "read" status for messages and says it is an essential feature of > > Telegram. > > > > I call it a violation of the receivers privacy. > > 100% agreed. +1 > > > It would be nice, if we (FreeBSD) could add (as a patch in the > > ports > > tree) a configuration value to the telegram-cli which does not > > send such notifications when the configuration says so. > > > > What do you (all and Maintainer) think about? > > That would be very useful, yes. I'll take a look ASAP, but first I need to finish my pending work :) > -- Carlos Jacobo Puga Medina PGP fingerprint = C60E 9497 5302 793B CC2D BB89 A1F3 5D66 E6D0 5453 signature.asc Description: This is a digitally signed message part
Re: Telegram-cli Issues
On 2015-Aug-05, 11:35, Aric Gregson wrote: > Hello, > > I am no longer able to make net-im/telegram-cli work. I believe this > happened when I upgraded to 10.1 some time ago. I have reinstalled the > program via portmaster several times to no avail. both 1.0.5.1_1 and 1.3.1 work fine here (10.1-RELEASE-p16 amd64). -- Pietro Cerutti The FreeBSD Project g...@freebsd.org PGP Public Key: http://gahr.ch/pgp pgpap49VFnlan.pgp Description: PGP signature
Re: skype ports status and expectations
El día Friday, July 31, 2015 a las 09:51:24AM +0300, Sergey V. Dyatko escribió: > I'm using FreeBSD-CURRENT (amd64) + net-im/skype4. All works fine (I hope). > http://gyazo.com/258a43fcb34ea384482800fa3d3de464 Could you please share the SVN rev. of your CURRENT or the output of 'uname -a'. Thanks matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ ☎ +49-176-38902045 No! Nein! ¡No! Όχι! -- Ευχαριστούμε! ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Telegram-cli Issues
On Thu, 6 Aug 2015, Matthias Apitz wrote: > The Telegram protocol and clients have a feature to shown to the sender > when the receiver has read the message, Telegram Support calls this > "read" status for messages and says it is an essential feature of > Telegram. > > I call it a violation of the receivers privacy. Just to go a little OT here, I once used one of those office all-in-one systems known as OfficePower (and at least one list member here is aware of it; hi Peter!). Anyway, it had this annoying "feature" called "View Ack", but at least you were warned about it, but worse, the sender was notified that you refused to view it. Well, me being me, I sort of viewed this as a gross violation of my privacy, but this was the 80s after all, when marketoids and middle managers were rampant (and I still loathe both species). A cow-orker came to my aid, and he showed me how to edit the message to remove the "View Ack" flag (I think I still have that script somewhere) so that it could be read safely; thanks, MikB. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." Watson never said: "I think there is a world market for maybe five computers." ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: skype ports status and expectations
Here you are: https://svnweb.freebsd.org/ports?view=revision&revision=389223 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200608 __FreeBSD_version >= 1100075, but I don't know actual revision. In any case, you can use latest CURRENT snapshot, it will work. On Thu, Aug 6, 2015 at 9:10 PM, Matthias Apitz wrote: > El día Friday, July 31, 2015 a las 09:51:24AM +0300, Sergey V. Dyatko > escribió: > > > I'm using FreeBSD-CURRENT (amd64) + net-im/skype4. All works fine (I > hope). > > http://gyazo.com/258a43fcb34ea384482800fa3d3de464 > > Could you please share the SVN rev. of your CURRENT or the output of > 'uname -a'. Thanks > > matthias > -- > Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ ☎ > +49-176-38902045 > No! Nein! ¡No! Όχι! -- Ευχαριστούμε! > ___ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" > ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Telegram-cli Issues
OK. I am not sure what I was doing with 1.0.5.1, but I have updated to 1.3 and it is working. It appears that there have been significant changes, but all is good. Thank you very much for getting this port together. Does anyone know of a way to listen to audio in the cli? Thanks, Aric ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Unable to relocate to new svn URL
On 2015-08-06 05:44, Kevin Oberman wrote: > ... > > This still leaves the issue of requiring SASL support in subversion. A note > in the handbook section on ports would help, though I'll admit that I > probably would not have found it in this case. Perhaps a note in > ports/UPDATING might be in order. At least that one was fairly easy to find > once I started looking. Hi Kevin, SASL support is not required to checkout/update src/ports/docs To see a list of client features fire the command $ svn --version svn, version 1.8.14 (r1692801) ... The following repository access (RA) modules are available: * ra_svn : Module for accessing a repository using the svn network protocol. - handles 'svn' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme * ra_serf : Module for accessing a repository via WebDAV protocol using serf. - using serf 1.3.8 - handles 'http' scheme - handles 'https' scheme or on FreeBSD >= 10.x $ svnlite --version svn, version 1.8.10 (r1615264) ... The following repository access (RA) modules are available: * ra_svn : Module for accessing a repository using the svn network protocol. - handles 'svn' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme * ra_serf : Module for accessing a repository via WebDAV protocol using serf. - using serf 1.3.7 - handles 'http' scheme - handles 'https' scheme -- olli ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
devel/subversion staging, won't install.
I've a note in devel/subversion that it failed to install in March this year... Just then (aug 6) it again fails to install [ terse kwallet-dynamic-lib something, broken install line in built-already install-from-stage ; the relevant ?? option is deselected ]. Maybe someone knows if some option is mandatory, or something else... I've BDB, DOCS, FREEBSD_TEMPLATE, NLS, P4_STYLE_MARKERS, SERF, SVNSERVE_WRAPPER but not the maybe relevant KDE_KWALLET ... As before, reinstalled the older version using pkg. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Proposal: make portsnap generate INDEX-${OSREL:R} only by default
Hi,
Currently the default portsnap.conf would generate INDEX-11, INDEX-10
and INDEX-9. The INDEX file is only used for searching ports, and only
one (INDEX-${OSREL:R}) file is actually used.
Traditionally, we create all supported INDEX-* files by default, but the
only users who would benefit from this default are the ones who shares
ports tree across many systems that runs different FreeBSD releases.
And even in these scenario, it's likely that they would still want to
tweak the configuration, as we may be creating more than needed INDEX-*
files.
So for simplicity and to reduce cycles wasted on everyone's system, I'd
propose the attached change to head/'s portsnap.conf and similar changes
to stable/9 and stable/10's portsnap.conf so that only INDEX-${OSREL:R}
is created by default. Users who want additional INDEX files can
uncomment the corresponding lines.
Any objections/concerns? I'll commit the change if no objection is
raised in a week.
Cheers,
--
Xin LI https://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
Index: etc/portsnap.conf
===
--- etc/portsnap.conf (revision 286392)
+++ etc/portsnap.conf (working copy)
@@ -30,6 +30,6 @@
# REFUSE korean polish portuguese russian ukrainian vietnamese
# List of INDEX files to build and the DESCRIBE file to use for each
-INDEX INDEX-9 DESCRIBE.9
-INDEX INDEX-10 DESCRIBE.10
+#INDEX INDEX-9 DESCRIBE.9
+#INDEX INDEX-10 DESCRIBE.10
INDEX INDEX-11 DESCRIBE.11
signature.asc
Description: OpenPGP digital signature
Re: Unable to relocate to new svn URL
On Thu, Aug 6, 2015 at 1:57 PM, olli hauer wrote: > On 2015-08-06 05:44, Kevin Oberman wrote: > > > ... > > > > This still leaves the issue of requiring SASL support in subversion. A > note > > in the handbook section on ports would help, though I'll admit that I > > probably would not have found it in this case. Perhaps a note in > > ports/UPDATING might be in order. At least that one was fairly easy to > find > > once I started looking. > > Hi Kevin, > > SASL support is not required to checkout/update src/ports/docs > > To see a list of client features fire the command > > $ svn --version > svn, version 1.8.14 (r1692801) > ... > The following repository access (RA) modules are available: > > * ra_svn : Module for accessing a repository using the svn network > protocol. > - handles 'svn' scheme > * ra_local : Module for accessing a repository on local disk. > - handles 'file' scheme > * ra_serf : Module for accessing a repository via WebDAV protocol using > serf. > - using serf 1.3.8 > - handles 'http' scheme > - handles 'https' scheme > > > or on FreeBSD >= 10.x > > $ svnlite --version > svn, version 1.8.10 (r1615264) > ... > The following repository access (RA) modules are available: > > * ra_svn : Module for accessing a repository using the svn network > protocol. > - handles 'svn' scheme > * ra_local : Module for accessing a repository on local disk. > - handles 'file' scheme > * ra_serf : Module for accessing a repository via WebDAV protocol using > serf. > - using serf 1.3.7 > - handles 'http' scheme > - handles 'https' scheme > > > -- > olli > I have been running subversion for years without SASL using svn scheme with no issues, but when I issued the command "svn relocate svn://svn0.us-west https://svn";, I got an error that the format of the new location was unsupported. I changed the config for subversion to add SASL support and reinstalled it. Then it worked except for failing to authenticate the cert. (I don't have the exact message any longer.) Since the only thing that changed between the failure and success was the change of adding SASL support, it sure looked like it was needed. Now that I have certs installed into /etc/ssl, the version without SASL is working. I wonder if the lack of certs caused serf to throw the error, but adding SASL allowed https to be accepted and got it to almost work. In any case, I just moved my /usr/src to https://svn with no SASL module installed but the certs in place and it worked fine. -- Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Proposal: make portsnap generate INDEX-${OSREL:R} only by default
On Thu, Aug 6, 2015 at 5:19 PM, Xin Li wrote:
> Hi,
>
> Currently the default portsnap.conf would generate INDEX-11, INDEX-10
> and INDEX-9. The INDEX file is only used for searching ports, and only
> one (INDEX-${OSREL:R}) file is actually used.
>
> Traditionally, we create all supported INDEX-* files by default, but the
> only users who would benefit from this default are the ones who shares
> ports tree across many systems that runs different FreeBSD releases.
> And even in these scenario, it's likely that they would still want to
> tweak the configuration, as we may be creating more than needed INDEX-*
> files.
>
> So for simplicity and to reduce cycles wasted on everyone's system, I'd
> propose the attached change to head/'s portsnap.conf and similar changes
> to stable/9 and stable/10's portsnap.conf so that only INDEX-${OSREL:R}
> is created by default. Users who want additional INDEX files can
> uncomment the corresponding lines.
>
> Any objections/concerns? I'll commit the change if no objection is
> raised in a week.
>
> Cheers,
> --
> Xin LI https://www.delphij.net/
> FreeBSD - The Power to Serve! Live free or die
>
Isn't rebuilding the index useful for people running STABLE? I assume that
I need a current index to get useful output from "pkg version -vL=". I am
probably a bit unusual in that I keep a current ports tre on a STABLE
system, but there are a couple of ports that I need to build due to custom
options and I find poudriere overkill for this case. I suspect many people
running STABLE may use portsnap and build everything from ports. (This use
to be common fairly recently and likely still is.)
Or, am I missing the obvious... something I seem to do too often these days.
--
Kevin Oberman, Network Engineer, Retired
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Proposal: make portsnap generate INDEX-${OSREL:R} only by default
Kevin Oberman wrote: > Isn't rebuilding the index useful for people running STABLE? I assume that > I need a current index to get useful output from "pkg version -vL=". I am > probably a bit unusual in that I keep a current ports tre on a STABLE > system, but there are a couple of ports that I need to build due to custom > options and I find poudriere overkill for this case. I suspect many people > running STABLE may use portsnap and build everything from ports. (This use > to be common fairly recently and likely still is.) I run stable, and compile from source with a current ports tree on all my machines too. But... > Or, am I missing the obvious... something I seem to do too often these days. ... maybe I'm missing something that you haven't missed, which is more likely! : I've already altered my portsnap.conf to only produce INDEX-10, and from what I can gather, this is basically what Xin Li is proposing becomes the default..., i.e. only produce INDEX-9 for 9.X, INDEX-10 for 10.X and INDEX-11 for 11.X Isn't it the case that the index required is 'tuned' to the dependencies each port requires based on base software (e.g. the index file on 10.X upwards won't list a dependency on converters/libiconv) so even if you portsnap your ports tree, it's still INDEX-10 you'd require on a FreeBSD-10.X machine..? Cheers, Jamie ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Proposal: make portsnap generate INDEX-${OSREL:R} only by default
On Thu, Aug 6, 2015 at 9:58 PM, Jamie Landeg-Jones wrote: > Kevin Oberman wrote: > > > Isn't rebuilding the index useful for people running STABLE? I assume > that > > I need a current index to get useful output from "pkg version -vL=". I am > > probably a bit unusual in that I keep a current ports tre on a STABLE > > system, but there are a couple of ports that I need to build due to > custom > > options and I find poudriere overkill for this case. I suspect many > people > > running STABLE may use portsnap and build everything from ports. (This > use > > to be common fairly recently and likely still is.) > > I run stable, and compile from source with a current ports tree on all my > machines too. > > But... > > > Or, am I missing the obvious... something I seem to do too often these > days. > > ... maybe I'm missing something that you haven't missed, which is more > likely! : > > I've already altered my portsnap.conf to only produce INDEX-10, and from > what I > can gather, this is basically what Xin Li is proposing becomes the > default..., > i.e. only produce INDEX-9 for 9.X, INDEX-10 for 10.X and INDEX-11 for 11.X > > Isn't it the case that the index required is 'tuned' to the dependencies > each > port requires based on base software (e.g. the index file on 10.X upwards > won't > list a dependency on converters/libiconv) so even if you portsnap your > ports > tree, it's still INDEX-10 you'd require on a FreeBSD-10.X machine..? > > Cheers, > Jamie > Yes, I was missing the obvious. I am a bit concerned about some edge cases involving system upgrades. Of course, if everyone follows recommendation and rebuilds all ports after a major version upgrade, it should work fine. Or the code in portsnap could be modified to get the current running version. This would need to be an option that could be turned off for the few people who actually need more than one index file. Still, looks like a good idea to me! -- Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Proposal: make portsnap generate INDEX-${OSREL:R} only by default
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 8/6/15 22:24, Kevin Oberman wrote: > Or the code in portsnap could be modified to get the current > running version. I thought about this today but it won't work as advertised: someone (currently me) still have to tweak the portsnap builder configuration to announce new major version (9, 10, 11 now, and we would need 12 when 11.0-STABLE appears). However, freebsd-update or mergemaster would take care for this. Cheers, -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVxEYEAAoJEJW2GBstM+ns6wkP/AoQS/GX6RfJ0r5KBzHJzo1Z 1sFGkqULBYbiS4DNV8Svt1+mMdg0IwK7t5vYhkiQI/RrkeddvU1btDiVPjNGbC3K Wm5wKAD2uMRLczz9EhKCZehDRq88ckvUMefPdT5R3b+DTo4VKdCXoPC4AqZnu7bb 60wnOL6cyKw8fwKTHhVyui6zcbg9uj7VtGj9MGK+03jHDmekJ6sXZO/0fp/TGju6 ruPVf9yImi9o/T5IUaKlj2D3xfDtwEhjI7Q96K4C5y88Tl5+PXQBh/07SQOKIu59 nalLbAH8eoxITWEAOBFjM/e1KOLH5Hyk+TfR0GXDZVLyL4mi8eIpch0eLFHp3e94 PEbsE1lUN3R3/4IFTmPDj1WYF9dE/AUgV4gzQKBboieVYNLfuL/esI0VOCFa/3r3 3rSW9RAj8MOH3GA3un14eUrWg5prvDcjMq9cJUO5Pebc3cD0CxlKCJ+yNAMlTo4Q 07u8dxBXsZcO//xknW5Gx9rKl+fJxvwy2klLmsiR3+bM2PCd1bt4bvSkOTgv1ZOt qJZ4g/sDpF2jx3UYj2PF5vnBLkI6RrWer379q8ZqAwVRGE4Z9glnzo9BNUpQoQDy PXzf3Nsj/qWkvnXXIWxI71rLTsKNejiXpBiYYjZV2eYz9dCveNJEMRFmHQ+xthHz VrdB3J9EBHa17p5Xlt2y =nN8J -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Proposal: make portsnap generate INDEX-${OSREL:R} only by default
On Thu, Aug 06, 2015 at 05:19:54PM -0700, Xin Li wrote:
> Hi,
>
> Currently the default portsnap.conf would generate INDEX-11, INDEX-10
> and INDEX-9. The INDEX file is only used for searching ports, and only
> one (INDEX-${OSREL:R}) file is actually used.
>
This is default behaviour for other tools like fetchindex already. It
makes no sense to have all INDEXes installed on all systems for almost
all users, so I'm all for it. The few corner cases can, say someone
building packages for different releases, can be easily scripted around
(or recommend poudriere).
Erwin
pgpycTJTv88g5.pgp
Description: PGP signature
