Re: Deprecation of portsnap
On 2021-04-13 23:22, Stefan Esser wrote: Am 14.04.21 um 02:43 schrieb Chris: On 2021-04-13 15:53, Dave Horsfall wrote: On Mon, 12 Apr 2021, Peter Jeremy via freebsd-ports wrote: Except that git will arbitrarily and randomly decide that it needs to run "gc" - which is similarly extravagant in memory usage. Last time I found one running, it thrashed that poor VM for 3 days. Would this be a good time to mention the https://ohshitgit.com/ site? Warning: it contains strong language... It would! And the language is very appropriate, thank you. :-) If you disagree regarding the appropriateness of the language, Not at all. I found the site absolutely *wonderful*. Thanks! :-) there is: https://dangitgit.com/ And in the upper right corner you'll find a language selection list that gives access to some 20 translations. Or just try the URL with your 2-letter country code added ... Regards, STefan ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Deprecation of portsnap
Am 14.04.21 um 02:43 schrieb Chris: On 2021-04-13 15:53, Dave Horsfall wrote: On Mon, 12 Apr 2021, Peter Jeremy via freebsd-ports wrote: Except that git will arbitrarily and randomly decide that it needs to run "gc" - which is similarly extravagant in memory usage. Last time I found one running, it thrashed that poor VM for 3 days. Would this be a good time to mention the https://ohshitgit.com/ site? Warning: it contains strong language... It would! And the language is very appropriate, thank you. :-) If you disagree regarding the appropriateness of the language, there is: https://dangitgit.com/ And in the upper right corner you'll find a language selection list that gives access to some 20 translations. Or just try the URL with your 2-letter country code added ... Regards, STefan OpenPGP_signature Description: OpenPGP digital signature
Re: Deprecation of portsnap
On 2021-04-13 15:53, Dave Horsfall wrote: On Mon, 12 Apr 2021, Peter Jeremy via freebsd-ports wrote: Except that git will arbitrarily and randomly decide that it needs to run "gc" - which is similarly extravagant in memory usage. Last time I found one running, it thrashed that poor VM for 3 days. Would this be a good time to mention the https://ohshitgit.com/ site? Warning: it contains strong language... It would! And the language is very appropriate, thank you. :-) -- Dave --Chris ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Deprecation of portsnap (was: Proposed ports git transition schedule)
> On 14. Apr 2021, at 00:54, Dave Horsfall wrote: > > On Mon, 12 Apr 2021, Peter Jeremy via freebsd-ports wrote: > >> Except that git will arbitrarily and randomly decide that it needs to run >> "gc" - which is similarly extravagant in memory usage. Last time I found >> one running, it thrashed that poor VM for 3 days. > Would this be a good time to mention the https://ohshitgit.com/ site? > Warning: it contains strong language... I prefer this site: https://git-man-page-generator.lokaltog.net/ -m > > -- Dave > ___ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Deprecation of portsnap (was: Proposed ports git transition schedule)
On Mon, 12 Apr 2021, Peter Jeremy via freebsd-ports wrote: Except that git will arbitrarily and randomly decide that it needs to run "gc" - which is similarly extravagant in memory usage. Last time I found one running, it thrashed that poor VM for 3 days. Would this be a good time to mention the https://ohshitgit.com/ site? Warning: it contains strong language... -- Dave ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Portsnap restoration after Git migration
On Mon, 12 Apr 2021 16:02:41 -0400 Ed Maste wrote: > Colin (cperciva) and I are making good progress on the portsnap build > infrastructure Git migration. I'll follow up when it is back in > operation. Thank you! ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Portsnap restoration after Git migration
Colin (cperciva) and I are making good progress on the portsnap build infrastructure Git migration. I'll follow up when it is back in operation. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Deprecation of portsnap (was: Proposed ports git transition schedule)
> On 12. Apr 2021, at 13:12, Peter Jeremy via freebsd-ports > wrote: > > On 2021-Apr-11 14:27:27 +0200, Helge Oldach wrote: >> Peter Jeremy via freebsd-ports wrote on Sun, 11 Apr 2021 00:52:11 +0200 >> (CEST): >>> Following the SVN to GIT migration, portsnap is now the only practical >>> way to use ports on a low-memory system. I've done some experiments >>> and standard git has a 2GB working set to checkout a ports tree. >> >> However checking out is a one-time action with ports as there is only >> one branch (switching frequently between main and quarterly is probably >> not very sensible on a limited machine). git pull is significantly more >> lightweight, I've just seen some 200M RSS. That should work well even on >> a 512M machine. Probably much better than gitup in constrained memory? > > Except that git will arbitrarily and randomly decide that it needs to > run "gc" - See https://git-scm.com/docs/git-gc for an explanation of how git decides when to run gc and how you can control it (e.g., by setting gc.auto to 0). -m > which is similarly extravagant in memory usage. Last time > I found one running, it thrashed that poor VM for 3 days. > > Ignoring that, a "git up -ff" on a ports tree peaks with 2×1GB processes, > though it looks like the working set size might only be ~350MB. > > -- > Peter Jeremy ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Deprecation of portsnap (was: Proposed ports git transition schedule)
On 2021-Apr-11 14:27:27 +0200, Helge Oldach wrote: >Peter Jeremy via freebsd-ports wrote on Sun, 11 Apr 2021 00:52:11 +0200 (CEST): >> Following the SVN to GIT migration, portsnap is now the only practical >> way to use ports on a low-memory system. I've done some experiments >> and standard git has a 2GB working set to checkout a ports tree. > >However checking out is a one-time action with ports as there is only >one branch (switching frequently between main and quarterly is probably >not very sensible on a limited machine). git pull is significantly more >lightweight, I've just seen some 200M RSS. That should work well even on >a 512M machine. Probably much better than gitup in constrained memory? Except that git will arbitrarily and randomly decide that it needs to run "gc" - which is similarly extravagant in memory usage. Last time I found one running, it thrashed that poor VM for 3 days. Ignoring that, a "git up -ff" on a ports tree peaks with 2×1GB processes, though it looks like the working set size might only be ~350MB. -- Peter Jeremy signature.asc Description: PGP signature
Re: Deprecation of portsnap (was: Proposed ports git transition schedule)
On Apr 11, 2021, at 06:27, free...@oldach.net wrote: > > However checking out is a one-time action with ports as there is only > one branch It sure looks like gitup is checking the entire port tree every single time. If I run it twice in a row it is no faster the second time. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Deprecation of portsnap (was: Proposed ports git transition schedule)
On 2021-Apr-01 12:19:08 +0200, Felix Palmen wrote: >* Christoph Moench-Tegeder [20210326 19:45]: >> ## Felix Palmen (fe...@palmen-it.de): >> >> > I'd assume (someone may correct me) that portsnap will still be >> > supported, >> >> https://lists.freebsd.org/pipermail/freebsd-ports/2020-August/119098.html > >Is this finally decided, and is there a timeline? Right now, it seems >portsnap is still built by default on releng/13.0. Following the SVN to GIT migration, portsnap is now the only practical way to use ports on a low-memory system. I've done some experiments and standard git has a 2GB working set to checkout a ports tree. gitup reached a 5GB working set size before I gave up. Typical small VPSs are around the 1GB RAM size and moving to something that can support 2GB or 5GB processes is a big price jump. -- Peter Jeremy signature.asc Description: PGP signature
Re: Deprecation of portsnap (was: Proposed ports git transition schedule)
On 01 Apr 2021, at 04:19, Felix Palmen wrote: > * Christoph Moench-Tegeder [20210326 19:45]: >> ## Felix Palmen (fe...@palmen-it.de): >>> I'd assume (someone may correct me) that portsnap will still be >>> supported, >> https://lists.freebsd.org/pipermail/freebsd-ports/2020-August/119098.html > Is this finally decided, and is there a timeline? That post I read as the official decision that port snap was going to die. But WITHOUT_PORTSANP added to the default base would be the single, I'd think. Most of the ground work has already been done. > portsnap is still built by default on releng/13.0. We'll see if it makes it to RELEASE or not. gitup is working well right now, but it looks more fiddly and I wish the 'fake JSON' configuration file was actual valid JSON, OTOH, it seems o run a lot faster than portsnap. -- I WILL NOT TRADE PANTS WITH OTHERS Bart chalkboard Ep. 7F05 ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Deprecation of portsnap (was: Proposed ports git transition schedule)
Hallo Christoph,
* Christoph Moench-Tegeder [20210326 19:45]:
> ## Felix Palmen (fe...@palmen-it.de):
>
> > I'd assume (someone may correct me) that portsnap will still be
> > supported,
>
> https://lists.freebsd.org/pipermail/freebsd-ports/2020-August/119098.html
Is this finally decided, and is there a timeline? Right now, it seems
portsnap is still built by default on releng/13.0.
--
Dipl.-Inform. Felix Palmen ,.//..
{web} http://palmen-it.de {jabber} [see email] ,//palmen-it.de
{pgp public key} http://palmen-it.de/pub.txt // """""""""""
{pgp fingerprint} A891 3D55 5F2E 3A74 3965 B997 3EF2 8B0A BC02 DA2A
signature.asc
Description: PGP signature
Re: portsnap
On Wed, 30 Dec 2020 11:02:55 -0700 Edward Sanford Sutton, III wrote: > portsnap is a shell script where fetch is used for downloads. It uses fetch for some things, but fetching the actual updates uses phttpget(8) which supports pipelined HTTP requests. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: portsnap
On 12/28/20 6:06 PM, Thomas Mueller wrote: >> Kudos to Stefan for keeping portmaster relevant and up-to-date. >> But I never understood the appeal of portsnap. What's the advantage over > >> svnlite co ... >> cd /usr/ports; make update > >> This mechanism is in the base system, so an extra tool demands some >> justification ;-) portsnap was much faster for small updates and slower for big updates last I tested it though I've heard it was the exact opposite for other's experiences. I found svn always had a certain overhead to run through my tree to make sure it was in sync where portsnap just said, "yup, snapshot up to date/needs these few changes" much quicker than my system could even walk a ports tree. Once months of changes are there I would have been better off with a fresh fetch effort I presume but doing the usual update was SLOW. If you want to just have a ports tree and have no intention of modifying it, tracking said changes, and/or submitting those patches back, or if you want to have the most up to date copy of the ports tree, download a copy from a specific changeset or moment in time, or if you want to downgrade certain ports then I think portsnap has always been the wrong choice. >> Kind regards, >> Patrick > >> punkt.de GmbH >> Patrick M. Hausen > > Better yet, I built the full subversion from FreeBSD ports and NetBSD pkgsrc so am able to use from either FreeBSD or NetBSD. > > But the useful days of svnlite or svn with FreeBSD with ports tree seem to end with the migration to git scheduled for the end of next March; already ended for FreeBSD doc and current src trees. portsnap didn't have an upload and svn won't disappear from read only view anytime soon; legacy FreeBSD support doesn't want that dying off until their versions last using it die off too. > I guess svnlite will be dropped from FreeBSD when it will no longer be usable. > > Any way portsnap can be updated to deal with a git repository? portsnap doesn't deal with a svn repository but uses its own effort to track changes if I recall. I didn't think the reason for going away was svn vs git. portsnap is a shell script where fetch is used for downloads. > I switched from portsnap to subversion following FreeBSD's switch from csup to subversion for security reasons in summer 2012 (to the best of my memory). > > I figured if I needed subversion to update src and doc trees, may as well also use it with ports tree: one-stop shopping. > > Tom > > ___ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" > ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: portsnap
> Kudos to Stefan for keeping portmaster relevant and up-to-date. > But I never understood the appeal of portsnap. What's the advantage over > svnlite co ... > cd /usr/ports; make update > This mechanism is in the base system, so an extra tool demands some > justification ;-) > Kind regards, > Patrick > punkt.de GmbH > Patrick M. Hausen Better yet, I built the full subversion from FreeBSD ports and NetBSD pkgsrc so am able to use from either FreeBSD or NetBSD. But the useful days of svnlite or svn with FreeBSD with ports tree seem to end with the migration to git scheduled for the end of next March; already ended for FreeBSD doc and current src trees. I guess svnlite will be dropped from FreeBSD when it will no longer be usable. Any way portsnap can be updated to deal with a git repository? I switched from portsnap to subversion following FreeBSD's switch from csup to subversion for security reasons in summer 2012 (to the best of my memory). I figured if I needed subversion to update src and doc trees, may as well also use it with ports tree: one-stop shopping. Tom ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: portsnap
Hi all, > Am 28.12.2020 um 16:38 schrieb Kevin Oberman : > > portsnap(8) predates svnlite by quite a bit, but you have just described > why it is not really worth the overhead of maintaining it. As bugzilla > describes many ticket closures, Overcome by events". Somehow I must have missed/skipped it. I used cvsup and later csup all the time it was available. While the migration from CVS to Subversion took place in 2008 I think I remember the cvsup mirrors to have been up for quite some time afterwards. Feeding back from Subversion into a read-only CVS I figure? /usr/bin/svnlite was introduced in 2013 which leaves a 5 year period of interest. I could not find when cvsup/csup was finally terminated. Does anyone remember? Kind regards, Patrick -- punkt.de GmbH Patrick M. Hausen .infrastructure Kaiserallee 13a 76133 Karlsruhe Tel. +49 721 9109500 https://infrastructure.punkt.de i...@punkt.de AG Mannheim 108285 Geschäftsführer: Jürgen Egeling, Daniel Lienert, Fabian Stein signature.asc Description: Message signed with OpenPGP
Re: portsnap
On Mon, Dec 28, 2020 at 4:37 AM Patrick M. Hausen wrote: > Hi all, > > > Am 26.12.2020 um 20:04 schrieb LuMiWa via freebsd-ports < > freebsd-ports@freebsd.org>: > > ...and I will continue to use portmaster. But I don't understand why > > we should no keep portsnap. > > Kudos to Stefan for keeping portmaster relevant and up-to-date. > But I never understood the appeal of portsnap. What's the advantage over > > svnlite co ... > cd /usr/ports; make update > > This mechanism is in the base system, so an extra tool demands some > justification ;-) > > Kind regards, > Patrick > -- > punkt.de GmbH > Patrick M. Hausen > .infrastructure > > Kaiserallee 13a > 76133 Karlsruhe > > Tel. +49 721 9109500 > > https://infrastructure.punkt.de > i...@punkt.de > > AG Mannheim 108285 > Geschäftsführer: Jürgen Egeling, Daniel Lienert, Fabian Stein > > portsnap(8) predates svnlite by quite a bit, but you have just described why it is not really worth the overhead of maintaining it. As bugzilla describes many ticket closures, Overcome by events". -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: portsnap
Hi all, > Am 26.12.2020 um 20:04 schrieb LuMiWa via freebsd-ports > : > ...and I will continue to use portmaster. But I don't understand why > we should no keep portsnap. Kudos to Stefan for keeping portmaster relevant and up-to-date. But I never understood the appeal of portsnap. What's the advantage over svnlite co ... cd /usr/ports; make update This mechanism is in the base system, so an extra tool demands some justification ;-) Kind regards, Patrick -- punkt.de GmbH Patrick M. Hausen .infrastructure Kaiserallee 13a 76133 Karlsruhe Tel. +49 721 9109500 https://infrastructure.punkt.de i...@punkt.de AG Mannheim 108285 Geschäftsführer: Jürgen Egeling, Daniel Lienert, Fabian Stein signature.asc Description: Message signed with OpenPGP
Re: portsnap
On Sat, Dec 26, 2020, 20:04 LuMiWa via freebsd-ports < freebsd-ports@freebsd.org> wrote: > On Sat, 26 Dec 2020 19:51:37 +0100 > Stefan Esser wrote: > > > Am 26.12.20 um 18:41 schrieb LuMiWa via freebsd-ports: > > > Hi! > > > > > > Today I red again an email: > > > > > > Subject:[HEADS UP] Planned deprecation of portsnap > > > From: Steve Wills > > > Date: 2020-08-04 18:43:20 > > > > > > And as portsnap user I have a question: Do they planning > > > deprecation of portmaster too? > > > > No, I'm actively working on portmaster and have rewritten it from > > scratch for better performance (and additional features, e.g. building > > in a clean chroot jail, similar to synth or poudriere). > > > > I have been using that version for more than one year, but the > > functionality is not complete, yet. > > > > On a test system with > 2200 installed ports it takes less than 10 > > seconds to identify the ~600 out-of-date ports (that I keep in this > > state for testing of the upgrade strategy function), which is more > > than 30 times faster than the same operation with the "official" > > portmaster. > > > > Until completion of that version, I'll continue to maintain and > > update the current portmaster port ... > > > > Regards, STefan > > > > ...and I will continue to use portmaster. But I don't understand why > we should no keep portsnap. > IIRC, there was an email a while ago announcing the discontinuation of portsnap and explaining the reasoning behind this move. Regards Michael > -- > “Waiter! A cup of coffee without cream, please! > I’m sorry, sir, we have no cream, only milk, so can it be a coffee > without milk?” > > ― Ernst Lubitsch’s Ninotchka > ___ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" > ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: portsnap
On Sat, 26 Dec 2020 19:51:37 +0100 Stefan Esser wrote: > Am 26.12.20 um 18:41 schrieb LuMiWa via freebsd-ports: > > Hi! > > > > Today I red again an email: > > > > Subject:[HEADS UP] Planned deprecation of portsnap > > From: Steve Wills > > Date: 2020-08-04 18:43:20 > > > > And as portsnap user I have a question: Do they planning > > deprecation of portmaster too? > > No, I'm actively working on portmaster and have rewritten it from > scratch for better performance (and additional features, e.g. building > in a clean chroot jail, similar to synth or poudriere). > > I have been using that version for more than one year, but the > functionality is not complete, yet. > > On a test system with > 2200 installed ports it takes less than 10 > seconds to identify the ~600 out-of-date ports (that I keep in this > state for testing of the upgrade strategy function), which is more > than 30 times faster than the same operation with the "official" > portmaster. > > Until completion of that version, I'll continue to maintain and > update the current portmaster port ... > > Regards, STefan > ...and I will continue to use portmaster. But I don't understand why we should no keep portsnap. -- “Waiter! A cup of coffee without cream, please! I’m sorry, sir, we have no cream, only milk, so can it be a coffee without milk?” ― Ernst Lubitsch’s Ninotchka ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: portsnap
Am 26.12.20 um 18:41 schrieb LuMiWa via freebsd-ports: Hi! Today I red again an email: Subject:[HEADS UP] Planned deprecation of portsnap From: Steve Wills Date: 2020-08-04 18:43:20 And as portsnap user I have a question: Do they planning deprecation of portmaster too? No, I'm actively working on portmaster and have rewritten it from scratch for better performance (and additional features, e.g. building in a clean chroot jail, similar to synth or poudriere). I have been using that version for more than one year, but the functionality is not complete, yet. On a test system with > 2200 installed ports it takes less than 10 seconds to identify the ~600 out-of-date ports (that I keep in this state for testing of the upgrade strategy function), which is more than 30 times faster than the same operation with the "official" portmaster. Until completion of that version, I'll continue to maintain and update the current portmaster port ... Regards, STefan OpenPGP_signature Description: OpenPGP digital signature
Re: portsnap
On Sat, Dec 26, 2020 at 9:42 AM LuMiWa via freebsd-ports < freebsd-ports@freebsd.org> wrote: > Hi! > > Today I red again an email: > > Subject:[HEADS UP] Planned deprecation of portsnap > From: Steve Wills > Date: 2020-08-04 18:43:20 > > And as portsnap user I have a question: Do they planning deprecation of > portmaster too? > > Thank you. > -- > “Waiter! A cup of coffee without cream, please! > I’m sorry, sir, we have no cream, only milk, so can it be a coffee > without milk?” > > ― Ernst Lubitsch’s Ninotchka I'm confused. other than dealing with ports, I don't see any relation. One is a tool to update the ports tree on a system and the other is a tool to install or update installed ports, regardless of how the tree was updated. There are other non-deprecated ports that will continue to perform both functions. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
portsnap
Hi! Today I red again an email: Subject:[HEADS UP] Planned deprecation of portsnap From: Steve Wills Date: 2020-08-04 18:43:20 And as portsnap user I have a question: Do they planning deprecation of portmaster too? Thank you. -- “Waiter! A cup of coffee without cream, please! I’m sorry, sir, we have no cream, only milk, so can it be a coffee without milk?” ― Ernst Lubitsch’s Ninotchka ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: portsnap depreciation
On Fri, 18 Sep 2020 15:44:27 -0700, John Kennedy stated: >On Fri, Sep 18, 2020 at 08:17:35PM +, Pau Amma wrote: >> On 2020-09-18 17:58, Carmel NY wrote: >> > On Fri, 18 Sep 2020 13:43:48 +, Pau Amma stated: >> >> See >> >> https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/testing-poudriere.html#testing-poudriere-ports-tree >> >> and the next sections. >> > >> > According to the above page, "The most straightforward way is to >> > have Poudriere create a default ports tree for itself, using either >> > portsnap(8) (if running FreeBSD 12.1 or 11.4) or Subversion (if >> > running FreeBSD-CURRENT)" Am I to understand that if I am running >> > 11.4-RELEASE, I cannot use subversion? >> >> "The most straightforward", not "the only". You can definitely use >> Subversion with 11.4 if you wish or need to. What you no longer can >> do is use portsnap with -CURRENT. (I'll grant that "straightforward" >> may be in the eye of the beholder, though.) > >For my stuff, I pull my stuff into /usr/ports however I want (git, >long before it was fashionable in my case) and then just set up >poudriere to use that. I do a similar things with /usr/src, except I >want poudriere to have a static copy of that, just in case. > >[initial creation] > poudriere jail -c -j 12-2 -v 12.2 -m src=/usr/src > poudriere ports -c -m null -M /usr/ports -p master > > poudriere jail -l > > JAILNAME VERSIONARCH METHOD > TIMESTAMP PATH 12-2 12.2-BETA2 1202000 amd64 > src=/usr/src 2020-09-18 15:32:59 > /usr/local/poudriere/jails/12-2 > > The "-m null" (null method) lets you manage it however you want. > > If I look at my mounts during the build, with ZFS, I can see them: > > Filesystem SizeUsed Avail Capacity Mounted > on ... > /usr/ports 350G4.0G346G 1% > /usr/local/poudriere/data/.m/12-2-master/ref/usr/ports > /usr/ports/distfiles364G 17G346G 5% > /usr/local/poudriere/data/.m/12-2-master/ref/distfiles Thanks John, but that is definitely more complex than my needs require. -- Carmel pgpCC3Q_t_gta.pgp Description: OpenPGP digital signature
Re: portsnap depreciation
On Fri, Sep 18, 2020 at 08:17:35PM +, Pau Amma wrote: > On 2020-09-18 17:58, Carmel NY wrote: > > On Fri, 18 Sep 2020 13:43:48 +, Pau Amma stated: > >> See > >> https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/testing-poudriere.html#testing-poudriere-ports-tree > >> and the next sections. > > > > According to the above page, "The most straightforward way is to have > > Poudriere create a default ports tree for itself, using either > > portsnap(8) (if running FreeBSD 12.1 or 11.4) or Subversion (if running > > FreeBSD-CURRENT)" Am I to understand that if I am running 11.4-RELEASE, > > I cannot use subversion? > > "The most straightforward", not "the only". You can definitely use > Subversion with 11.4 if you wish or need to. What you no longer can do > is use portsnap with -CURRENT. (I'll grant that "straightforward" may be > in the eye of the beholder, though.) For my stuff, I pull my stuff into /usr/ports however I want (git, long before it was fashionable in my case) and then just set up poudriere to use that. I do a similar things with /usr/src, except I want poudriere to have a static copy of that, just in case. [initial creation] poudriere jail -c -j 12-2 -v 12.2 -m src=/usr/src poudriere ports -c -m null -M /usr/ports -p master poudriere jail -l JAILNAME VERSIONARCH METHOD TIMESTAMP PATH 12-2 12.2-BETA2 1202000 amd64 src=/usr/src 2020-09-18 15:32:59 /usr/local/poudriere/jails/12-2 The "-m null" (null method) lets you manage it however you want. If I look at my mounts during the build, with ZFS, I can see them: Filesystem SizeUsed Avail Capacity Mounted on ... /usr/ports 350G4.0G346G 1% /usr/local/poudriere/data/.m/12-2-master/ref/usr/ports /usr/ports/distfiles364G 17G346G 5% /usr/local/poudriere/data/.m/12-2-master/ref/distfiles ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: portsnap depreciation
On 2020-09-18 17:58, Carmel NY wrote: On Fri, 18 Sep 2020 13:43:48 +, Pau Amma stated: See https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/testing-poudriere.html#testing-poudriere-ports-tree and the next sections. According to the above page, "The most straightforward way is to have Poudriere create a default ports tree for itself, using either portsnap(8) (if running FreeBSD 12.1 or 11.4) or Subversion (if running FreeBSD-CURRENT)" Am I to understand that if I am running 11.4-RELEASE, I cannot use subversion? "The most straightforward", not "the only". You can definitely use Subversion with 11.4 if you wish or need to. What you no longer can do is use portsnap with -CURRENT. (I'll grant that "straightforward" may be in the eye of the beholder, though.) ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: portsnap depreciation
On Fri, Sep 18, 2020 at 01:58:29PM -0400, Carmel NY wrote: > On Fri, 18 Sep 2020 13:43:48 +, Pau Amma stated: > >On 2020-09-18 11:14, Carmel NY wrote: > >> Is 'portsnap' > >> going to be depreciated? > > > >Yes. > > > >> If so, when? > > > >I believe when 13.0 is released, or already if you're using a recent > >-current. > > > >> If is is depreciated, how will > >> this affect poudriere? > > > >See > >https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/testing-poudriere.html#testing-poudriere-ports-tree > > > >and the next sections. > > According to the above page, "The most straightforward way is to have > Poudriere create a default ports tree for itself, using either > portsnap(8) (if running FreeBSD 12.1 or 11.4) or Subversion (if running > FreeBSD-CURRENT)" Am I to understand that if I am running 11.4-RELEASE, > I cannot use subversion? > You can if you specify the -m (method) parameter when creating the poudriere ports tree. René ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: portsnap depreciation
On Fri, Sep 18, 2020 at 01:58:29PM -0400, Carmel NY wrote: > ... > >https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/testing-poudriere.html#testing-poudriere-ports-tree > > > >and the next sections. > > According to the above page, "The most straightforward way is to have > Poudriere create a default ports tree for itself, using either > portsnap(8) (if running FreeBSD 12.1 or 11.4) or Subversion (if running > FreeBSD-CURRENT)" Am I to understand that if I am running 11.4-RELEASE, > I cannot use subversion? > I don't see any reason why you cannot use subversion: I do, and have done, since 05 July 2015, running stable/10 at the time; now running stable/12. Peace, david -- David H. Wolfskill da...@catwhisker.org "President Trump can say whatever he likes, but his actions speak for themselves." -- Dan Berschinski, wounded US Army veteran See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: portsnap depreciation
On Fri, 18 Sep 2020 13:43:48 +, Pau Amma stated: >On 2020-09-18 11:14, Carmel NY wrote: >> Is 'portsnap' >> going to be depreciated? > >Yes. > >> If so, when? > >I believe when 13.0 is released, or already if you're using a recent >-current. > >> If is is depreciated, how will >> this affect poudriere? > >See >https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/testing-poudriere.html#testing-poudriere-ports-tree > >and the next sections. According to the above page, "The most straightforward way is to have Poudriere create a default ports tree for itself, using either portsnap(8) (if running FreeBSD 12.1 or 11.4) or Subversion (if running FreeBSD-CURRENT)" Am I to understand that if I am running 11.4-RELEASE, I cannot use subversion? -- Carmel pgpco7s6kGJJ9.pgp Description: OpenPGP digital signature
Re: portsnap depreciation
On 2020-09-18 11:14, Carmel NY wrote: Is 'portsnap' going to be depreciated? Yes. If so, when? I believe when 13.0 is released, or already if you're using a recent -current. If is is depreciated, how will this affect poudriere? See https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/testing-poudriere.html#testing-poudriere-ports-tree and the next sections. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
portsnap depreciation
Perhaps I am wrong on this, so I thought I would ask. Is 'portsnap' going to be depreciated? If so, when? If is is depreciated, how will this affect poudriere? I thought that poudriere used 'portsnap'. -- Carmel pgpu4e_OrLlmR.pgp Description: OpenPGP digital signature
Re: [HEADS UP] Planned deprecation of portsnap
Portsnap is convenient, but svn/git in more inline with other tools. Maybe some sort of middle ground where portsnap is replaced (or re-written) with a wrapper around the svn checkout/update (or git clone/pull) process. On 8/13/2020 3:30 AM, Tatsuki Makino wrote: We need to be reminded of csup once in a while :) Will portsnap be rewritten in C? :) ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
We need to be reminded of csup once in a while :) Will portsnap be rewritten in C? :) ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
On Mon, 10 Aug 2020, Robert Huff wrote: There are many users who never create any patches, but simply use the ports tree to install software. Add my name to that list. Mine too; this is a great way to drive "ordinary users" away from FreeBSD and towards, gasp, Penguin/OS... I took up FreeBSD when BSD/OS was shut down by WinDriver and found that the OpenBSD bods weren't too friendly towards newbies; the Mac is now my major system (with porting attempts to FreeBSD and Penguin, then back). Well, at least it has FreeBSD roots... (Used to use cvsup ... now subversion ... soon git ... where will the insanity end? :-) ) Hah! I started with SCCS :-) Before that we had an in-house system called SLUP (Source Line Update Program? This was in the 70s, and was based upon that canonical example of diff/ed). -- Dave ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
On Mon, 10 Aug 2020 12:11:06 -0400 Robert Huff roberth...@rcn.com said Michael Gmelin writes: > There are many users who never create any patches, but simply use > the ports tree to install software. Add my name to that list. (Used to use cvsup ... now subversion ... soon git ... where will the insanity end? :-) ) LOL it *won't*. In about 6mos from now, something shinny will appear on the horizon It's a bit like a dog chasing it's tail; it never ends. ;-) But I don't mind. So long as the svn server can be kept in sync. Respectfully, Robert Huff --Chris -- Get it right: _physical_ distancing; _social_ cohesion ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
On 8/11/20 9:39 PM, Mike Clarke wrote: On Sunday, 9 August 2020 17:27:01 BST RW via freebsd-ports wrote: What I'd like to see is a simple way to update the ports tree to match what was used to build the current packages in the repository. Something I've felt in need of for a long time, and suggested from time to time in the past. What we need is a pkg command which returns the revision number of the ports tree which was used to build the current repository. When provided with that information I could run "svnlite up -q -r $REV $PORTSDIR" to keep my ports and packages in sync. I also think that would be great. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
On Sunday, 9 August 2020 17:27:01 BST RW via freebsd-ports wrote: > What I'd like to see is a simple way to update the ports tree to match > what was used to build the current packages in the repository. Something I've felt in need of for a long time, and suggested from time to time in the past. What we need is a pkg command which returns the revision number of the ports tree which was used to build the current repository. When provided with that information I could run "svnlite up -q -r $REV $PORTSDIR" to keep my ports and packages in sync. -- Mike Clarke ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
On Fri, Aug 07, 2020 at 11:48:34AM -0400, Greg Veldman wrote: > On Fri, Aug 07, 2020 at 03:43:38PM +0200, Michael Gmelin wrote: > > The real question is: Will we design things in a way that we expect ports > > tree users to always install git and its dependencies on their system or > > not (long term)? > > > > For developers it???s a no-brainer (obviously yes), but ports tree users > > aren???t developers. > > Or alternatively, will there be a git/gitlite or similar utility > included in base that can be used to bootstrap one's ports tree? We'd love to have something, but we aren't going to hold up progress indefinitely waiting for one to be implemented in an acceptable language with an acceptable license. -- Brooks signature.asc Description: PGP signature
Re: [HEADS UP] Planned deprecation of portsnap
On Mon, Aug 10, 2020 at 3:21 PM Steve Wills wrote: > On 8/10/20 9:28 AM, Lars Engels wrote: > > On Tue, Aug 04, 2020 at 02:43:20PM -0400, Steve Wills wrote: > > > > I'm probably fine with this and I think that all of the (now) supported > > methods have pros and cons. > > To leverage the UX flaws of git and svn(lite) compared to portsnap > > having a wrapper script around the two tools would be very appreciated. > > > > Something like > > > > # portsnap-ng --mode git --branch 2020Q2 --destination /ports/2020Q2 fetch > > extract > >The package devel/git does not seem to be installed, do you want to > > install it? (Y/n) _ > > > > With sane defaults, so you can just run portsnap fetch extract like > > you're used to and this > > downloads the latest ports tree to /usr/ports using base svnlite(1). > > > > While we're here: Can we please have a separate user that is used to > > checkout the tree? > > > > Lars > > > > > > P.S.: Please DO NOT name the wrapper portsnap-ng. :-) > > > > I think something like this will likely in many ways perpetuate many of > the problems I listed in my original email, particularly with folks > being on the wrong branch and not properly generating patches. This seems to be an orthogonal issue. IMHO workflows to fix/update code which do not use a VCS are totally outdated. There should be no patches to fix things, but (git - if your VCS is git) branches. Then all these problems of "being on a wrong branch" are not there. Dima > > Steve > ___ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
Michael Gmelin writes: > There are many users who never create any patches, but simply use > the ports tree to install software. Add my name to that list. (Used to use cvsup ... now subversion ... soon git ... where will the insanity end? :-) ) Respectfully, Robert Huff -- Get it right: _physical_ distancing; _social_ cohesion ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
> On 10. Aug 2020, at 16:22, Steve Wills wrote: > > Hi, > >> On 8/10/20 9:28 AM, Lars Engels wrote: >> On Tue, Aug 04, 2020 at 02:43:20PM -0400, Steve Wills wrote: >> I'm probably fine with this and I think that all of the (now) supported >> methods have pros and cons. >> To leverage the UX flaws of git and svn(lite) compared to portsnap >> having a wrapper script around the two tools would be very appreciated. >> Something like >> # portsnap-ng --mode git --branch 2020Q2 --destination /ports/2020Q2 fetch >> extract >> The package devel/git does not seem to be installed, do you want to >> install it? (Y/n) _ >> With sane defaults, so you can just run portsnap fetch extract like >> you're used to and this >> downloads the latest ports tree to /usr/ports using base svnlite(1). >> While we're here: Can we please have a separate user that is used to >> checkout the tree? >> Lars >> P.S.: Please DO NOT name the wrapper portsnap-ng. :-) > > I think something like this will likely in many ways perpetuate many of the > problems I listed in my original email, particularly with folks being on the > wrong branch and not properly generating patches. There are many users who never create any patches, but simply use the ports tree to install software. Please make sure the ports collection keeps working for them. Michael ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
Hi, On 8/10/20 9:28 AM, Lars Engels wrote: On Tue, Aug 04, 2020 at 02:43:20PM -0400, Steve Wills wrote: I'm probably fine with this and I think that all of the (now) supported methods have pros and cons. To leverage the UX flaws of git and svn(lite) compared to portsnap having a wrapper script around the two tools would be very appreciated. Something like # portsnap-ng --mode git --branch 2020Q2 --destination /ports/2020Q2 fetch extract The package devel/git does not seem to be installed, do you want to install it? (Y/n) _ With sane defaults, so you can just run portsnap fetch extract like you're used to and this downloads the latest ports tree to /usr/ports using base svnlite(1). While we're here: Can we please have a separate user that is used to checkout the tree? Lars P.S.: Please DO NOT name the wrapper portsnap-ng. :-) I think something like this will likely in many ways perpetuate many of the problems I listed in my original email, particularly with folks being on the wrong branch and not properly generating patches. Steve ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
On Tue, Aug 04, 2020 at 02:43:20PM -0400, Steve Wills wrote: > > We are planning to deprecate use of portsnap in ports. > > The reasons are as follows (in no particular order): > > * Portsnap doesn't support quarterly branches, even years after > quarterly branches were created and changed to the default for non-HEAD > packages. > > * Portsnap doesn't seem to save disk space compared to svn or git, if > you count the metadata (stored in /var/db/portsnap by default) and you > do an apples-to-apples comparison of svn or git without history and > ignoring possible ZFS compression. That is, you use "svn export" or git > "clone --depth 1", you see this disk usage: > > 342Msvnexport > 426Mgit > 477Mportsnap > > * Portsnap also doesn't work offline which git does. With git, you can > also easily add the history by running "git pull --unshallow" > > * This migration away from portsnap fits well with the planned migration > to git. > > * Also based on the patches we've seen in Bugzilla for some time, usage > of portsnap causes folks to too easily accidentally submit patches to > Bugzilla which don't apply easily. > > * Since portsnap doesn't support quarterly branches, it often causes > users to build on the wrong branch or end up with mismatched packages. > That is, they install packages from quarterly via pkg, then want to > customize so run portsnap and build from head, which can cause problems, > as we often see. Even when this doesn't happen, it adds to > troubleshooting to verify that it didn't. > > We are aware people have gotten used to portsnap, but believe: > > * People should be able to easily use svnlite in base or git from pkgs. > (Very few people seem to actually use WITHOUT_SVNLITE). > > * There is also the possibility of falling back to fetching a tar or zip > from https://cgit-beta.freebsd.org/ports/ although this does make > updating harder. > > How it will be done, in order: > > * Update poudriere to use svn by default. This is already done: > > https://github.com/freebsd/poudriere/pull/764 > > https://github.com/freebsd/poudriere/commit/bd68f30654e2a8e965fbdc09aad238c8bf5cdc10 > > * Update docs not to mention portsnap. This is already in progress: > >https://reviews.freebsd.org/D25800 >https://reviews.freebsd.org/D25801 >https://reviews.freebsd.org/D25803 >https://reviews.freebsd.org/D25805 >https://reviews.freebsd.org/D25808 >https://svnweb.freebsd.org/changeset/base/363798 > >Many thanks to the folks who have worked and are working on this! > > * Make WITHOUT_PORTSNAP default in base. Currently not certain when this > will happen. May not happen before 13.0, but hopefully it will. > > * Eventually, portsnap servers will see low enough usage they can be > disabled. > > We welcome any constructive feedback. All input would be heard, and if > the plans need to be amended, we will come back to you with the amended > plan in a couple of weeks. This process will take some time and > hopefully won't be too disruptive to anyone's usual workflow. > I'm probably fine with this and I think that all of the (now) supported methods have pros and cons. To leverage the UX flaws of git and svn(lite) compared to portsnap having a wrapper script around the two tools would be very appreciated. Something like # portsnap-ng --mode git --branch 2020Q2 --destination /ports/2020Q2 fetch extract The package devel/git does not seem to be installed, do you want to install it? (Y/n) _ With sane defaults, so you can just run portsnap fetch extract like you're used to and this downloads the latest ports tree to /usr/ports using base svnlite(1). While we're here: Can we please have a separate user that is used to checkout the tree? Lars P.S.: Please DO NOT name the wrapper portsnap-ng. :-) ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
On Sun, 9 Aug 2020 16:43:28 +0100 Matthew Seaman wrote: > On 09/08/2020 07:03, Stefan Ehmann wrote: > > I usually run `pkg version` to see what packages have changed. > > > > Previously, that was a more or less instant operation, now it takes > > over 100 seconds. The problem is that /usr/ports/INDEX-12 is > > missing. > > Yes. For historical reason, the order of precedence for the source of > information about available packages that pkg(8) uses is: > >* INDEX file >* A checked-out copy of /usr/ports >* The pkg repository catalogue > > In my humble opinion, it's the third of those options that is actually > the best, both in terms of speed and accuracy. Inaccurate because the ports tree used to create the packages is typically a bit behind the current tree. What I'd like to see is a simple way to update the ports tree to match what was used to build the current packages in the repository. If you update most packages using pkg, but build a few locally, the difference in tree versions can cause problems. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
On 09/08/2020 07:03, Stefan Ehmann wrote: > I usually run `pkg version` to see what packages have changed. > > Previously, that was a more or less instant operation, now it takes over 100 > seconds. The problem is that /usr/ports/INDEX-12 is missing. Yes. For historical reason, the order of precedence for the source of information about available packages that pkg(8) uses is: * INDEX file * A checked-out copy of /usr/ports * The pkg repository catalogue In my humble opinion, it's the third of those options that is actually the best, both in terms of speed and accuracy. You can force pkg(8) to use the repository catalogue by either of: * Use the '-R' command line flag: `pkg version -vRL=` * Don't have an installed copy of /usr/ports -- either use the system pre-compiled packages or set up your own repo with poudriere(8) Second best is to use the ports INDEX: this is pretty quick, but has a few niggles about accuracy. For instance: I don't know if the INDEX handles package flavours properly yet. You can obtain a copy of the INDEX by: * cd /usr/ports ; make fetchindex (downloads a pre-built index) * cd /usr/ports ; make index(builds an index locally) Building your own index does take a non-trivial amount of time and CPU resources, but it does mean the INDEX reflects local customizations and options settings. Least useful is the situation where you have an installed ports tree but no INDEX file. In this case, pkg(8) will run make(1) to extract the needed dependency information, which, as you have already discovered, takes approximately forever. Cheers, Matthew signature.asc Description: OpenPGP digital signature
Re: [HEADS UP] Planned deprecation of portsnap
On Tuesday, August 4, 2020 8:43:20 PM CEST Steve Wills wrote: > We are planning to deprecate use of portsnap in ports. > > The reasons are as follows (in no particular order): > > * Portsnap doesn't support quarterly branches, even years after > quarterly branches were created and changed to the default for non-HEAD > packages. [...] The portsnap-servers seem to lack updates at the moment, so I decided to try to switch to SVN. I usually run `pkg version` to see what packages have changed. Previously, that was a more or less instant operation, now it takes over 100 seconds. The problem is that /usr/ports/INDEX-12 is missing. Looks like INDEX doesn't exist in SVN but was provided by portsnap. make index takes several minutes, so that's a quite a downgrade from portsnap where I got it for free. Are there any faster ways to regenerate INDEX? There's make fetchindex but that's not guaranteed to be in sync with the latest SVN. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
On 05 Aug 2020, at 04:59, Hans Petter Selasky wrote: > 2) Should portsnap be a wrapper for GIT/SVN whatever is used? Yes, this seems like a very obvious thing to do as it will minimize disruption for the most users. Not everyone has any use for git our any need to learn git syntax. A "portsnap" wrapper that duplicates existing functionality should be part of this change. -- 99 percent of lawyers give the rest a bad name. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
By the way, there was a REFUSE directive in /etc/portsnap.conf, wasn't there? Isn't this a db space saver? Or, rename the current fetch command to fetch-all. Then the fetch command will be modified to download only where it is needed based on the dependency graph. portsnap fetch # <- download Mk/*, INDEX-1? and result of pkg info -oqa portsnap extract # install it to /usr/ports make -C /usr/ports/ search "name=git-[0-9]" # find a git. -> Path: /usr/ports/devel/git portsnap fetch devel/git # download the git-related stuff. ftp/curl, lang/p5-Error, textproc/rubygem-asciidoctor, ... security/p5-Authen-SASL, security/p5-IO-Socket-SSL portsnap extract # Add a git-related tree. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
On Fri, Aug 07, 2020 at 03:43:38PM +0200, Michael Gmelin wrote: > The real question is: Will we design things in a way that we expect ports > tree users to always install git and its dependencies on their system or not > (long term)? > > For developers it???s a no-brainer (obviously yes), but ports tree users > aren???t developers. Or alternatively, will there be a git/gitlite or similar utility included in base that can be used to bootstrap one's ports tree? -- Greg Veldman free...@gregv.net ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
> On 7. Aug 2020, at 15:26, Steve Wills wrote: > > Hi, > . > I believe that's updated daily and the tars from cgit are generated at least > that frequently, if not more. > The real question is: Will we design things in a way that we expect ports tree users to always install git and its dependencies on their system or not (long term)? For developers it’s a no-brainer (obviously yes), but ports tree users aren’t developers. Ideally, from a user perspective, “portsnap fetch/extract/update” would just work as it did before (maybe running “portsnap reset/migrate” once after the change). Cheers, Michael ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
Hi, On 8/7/20 6:19 AM, Michael Gmelin wrote: On Fri, 7 Aug 2020 01:24:00 -0400 Steve Wills wrote: Hi, [snip] 2. Use svnlite to checkout a ports tree. (There will be git -> svn replication. Will this be a long-term option? I don't know yet exactly how long the git to svn migration is planned to be maintained. I would expect quite some time. [snip] 3. Download a tar of the ports tree either from: https://download.freebsd.org/ftp/ports/ports/ or cgit. Would work too, but relatively expensive. Also, how often would it be updated? I believe that's updated daily and the tars from cgit are generated at least that frequently, if not more. Steve ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
On 8/7/20 6:05 PM, Eugene Grosbein wrote: > 07.08.2020 18:10, Ashish SHUKLA wrote: > >> Is there a similar seed file for subversion snapshot, that one can >> download, extract, and "svn up" ? >> >> I was trying to "svn co" the ports tree, and it keeps dying in the >> middle of checkout every few minutes. > > ftp://ftp.freebsd.org/pub/FreeBSD/development/subversion/ > > Last updated Feb 26 2020, though. Still usable for update to current state. > That seems more like a seed for mirroring svn repository. I was hoping for a snapshot of "svn checkout ", and that I (as a user) could extract and "svn up" Thanks! -- Ashish | GPG: F682CDCC39DC0FEAE11620B6C746CFA9E74FA4B0 “Everybody is somebody else's weirdo.” (Edsger W. Dijkstra) signature.asc Description: OpenPGP digital signature
Re: [HEADS UP] Planned deprecation of portsnap
07.08.2020 18:10, Ashish SHUKLA wrote: > Is there a similar seed file for subversion snapshot, that one can > download, extract, and "svn up" ? > > I was trying to "svn co" the ports tree, and it keeps dying in the > middle of checkout every few minutes. ftp://ftp.freebsd.org/pub/FreeBSD/development/subversion/ Last updated Feb 26 2020, though. Still usable for update to current state. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
On 8/6/20 6:05 PM, Mathieu Arnold wrote:
> On Thu, Aug 06, 2020 at 02:11:10PM +0200, Michael Gmelin wrote:
>>
>>
>>> On 6. Aug 2020, at 13:58, Mathieu Arnold wrote:
>>>
>>> On Thu, Aug 06, 2020 at 12:17:37AM +0200, Michael Gmelin wrote:
> We welcome any constructive feedback. All input would be heard, and if
> the plans need to be amended, we will come back to you with the amended
> plan in a couple of weeks. This process will take some time and hopefully
> won't be too disruptive to anyone's usual workflow.
What will be the process to bootstrap git?
>>>
>>> pkg install git comes to mind.
>>>
>>
>> I obviously meant bootstrapping without relying on binary packages (for
>> multiple reasons) >_<
>>
>> E.g., pulling a tarball (from a github mirror or some other place) using
>> “fetch” to populate an intermediate ports tree to build git/other
>> dependencies. Shouldn’t be hard to do and easy to document.
>
> Well, you can download the head of the main branch,
> https://cgit-beta.freebsd.org/ports/snapshot/main.tar.gz and extract it
> wherever you like.
>
Is there a similar seed file for subversion snapshot, that one can
download, extract, and "svn up" ?
I was trying to "svn co" the ports tree, and it keeps dying in the
middle of checkout every few minutes.
Thanks!
--
Ashish | GPG: F682CDCC39DC0FEAE11620B6C746CFA9E74FA4B0
“In reality there are as many religions as there are individuals.”
("Mahatma Gandhi", "Hind Swaraj", 1908)
signature.asc
Description: OpenPGP digital signature
Re: [HEADS UP] Planned deprecation of portsnap
On Fri, 7 Aug 2020 01:24:00 -0400 Steve Wills wrote: > Hi, > > On 8/5/20 6:17 PM, Michael Gmelin wrote: > > > > > > What will be the process to bootstrap git? > > > > There are several options: Thanks for your response - ideally there would be a lean default way users can rely on (hence my question, I probably should've injected the word "standard" in there). > > 1. Install the git package provided by the FreeBSD project In many cases this is the obvious choice, but in some scenarios not possible. > 2. Use svnlite to checkout a ports tree. (There will be git -> svn > replication. Will this be a long-term option? I would very much like that - not for development, I'm more than happy that I can *finally* use git there in the future - but to have a chance to get and update a ports tree on hosts (and inside of jails etc.) without installing git and all its dependencies: (typical dependency output from some older host) git-2.27.0: p5-CGI-4.47 expat-2.2.8 p5-IO-Socket-SSL-2.068 p5-Authen-SASL-2.16_1 python37-3.7.7 perl5-5.30.3 p5-Error-0.17029 curl-7.70.0_1 pcre-8.44 p5-subversion-1.14.0 p5-Term-ReadKey-2.38_1 gettext-runtime-0.20.2 cvsps-2.1_2 This would also allow to write a simple/lean wrapper that can act as a drop-in replacement for portsnap, as it doesn't require a special bootstrap procedure and doesn't install any additional packages/binaries on the system - therefore existing jail managers and people's automation won't break. > 3. Download a tar of the ports tree either from: > https://download.freebsd.org/ftp/ports/ports/ > > or cgit. Would work too, but relatively expensive. Also, how often would it be updated? Thanks, Michael -- Michael Gmelin ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
Hi, On 8/5/20 6:17 PM, Michael Gmelin wrote: What will be the process to bootstrap git? There are several options: 1. Install the git package provided by the FreeBSD project 2. Use svnlite to checkout a ports tree. (There will be git -> svn replication. 3. Download a tar of the ports tree either from: https://download.freebsd.org/ftp/ports/ports/ or cgit. Steve ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
Mathieu Arnold wrote on 2020/08/06 20:57: > `svnlite cleanup --remove-unversioned` I have gained new knowledge. I had erased the files ? marked with the following svnlite status with my own hands :) # svnlite status "`cat /usr/local/etc/poudriere.d/ports/svn/mnt`" ? /usr/local/poudriere/ports/svn/graphics/gegl/files When we are doing a time-consuming checkout (e.g. checkout entire ports tree) and the line goes dead, corruption occurs that requires svnlite cleanup. If the documentation is written for beginners (or for me :) ) to that extent, I see no problem with it. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
On 2020-08-04 20:43, Steve Wills wrote: > We welcome any constructive feedback. All input would be heard, and if the > plans need to be amended, we will come back to you with the amended plan in a > couple of weeks. This process will take some time and hopefully won't be too > disruptive to anyone's usual workflow. As a total random user with no direct role in the ports life, except than being portsnap user, may I suggest that the "removal" may be instead a "replace" of the portsnap binary with a script or whatever that runs the "new-standard-method"? I mean, it took me ages to learn portsnap fetch and portsnap update, if I run them as usual I wouldn't care at all if behind the scenes it's doing a svn update, a git fetch or whatever you choose. I've been bitten hard by nslookup removal in the past year being done the hard way while a gentle "factory built-in" alias nslookup = host/dig/whatever would have saved me a lot of cursings... Thanks. --- Andrea Brancatelli ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
On Thu, Aug 06, 2020 at 02:11:10PM +0200, Michael Gmelin wrote: > > > > On 6. Aug 2020, at 13:58, Mathieu Arnold wrote: > > > > On Thu, Aug 06, 2020 at 12:17:37AM +0200, Michael Gmelin wrote: > >>> We welcome any constructive feedback. All input would be heard, and if > >>> the plans need to be amended, we will come back to you with the amended > >>> plan in a couple of weeks. This process will take some time and hopefully > >>> won't be too disruptive to anyone's usual workflow. > >> > >> What will be the process to bootstrap git? > > > > pkg install git comes to mind. > > > > I obviously meant bootstrapping without relying on binary packages (for > multiple reasons) >_< > > E.g., pulling a tarball (from a github mirror or some other place) using > “fetch” to populate an intermediate ports tree to build git/other > dependencies. Shouldn’t be hard to do and easy to document. Well, you can download the head of the main branch, https://cgit-beta.freebsd.org/ports/snapshot/main.tar.gz and extract it wherever you like. -- Mathieu Arnold signature.asc Description: PGP signature
Re: [HEADS UP] Planned deprecation of portsnap
> On 6. Aug 2020, at 13:58, Mathieu Arnold wrote: > > On Thu, Aug 06, 2020 at 12:17:37AM +0200, Michael Gmelin wrote: >>> We welcome any constructive feedback. All input would be heard, and if the >>> plans need to be amended, we will come back to you with the amended plan in >>> a couple of weeks. This process will take some time and hopefully won't be >>> too disruptive to anyone's usual workflow. >> >> What will be the process to bootstrap git? > > pkg install git comes to mind. > I obviously meant bootstrapping without relying on binary packages (for multiple reasons) >_< E.g., pulling a tarball (from a github mirror or some other place) using “fetch” to populate an intermediate ports tree to build git/other dependencies. Shouldn’t be hard to do and easy to document. -m ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
On Thu, Aug 06, 2020 at 12:17:37AM +0200, Michael Gmelin wrote: > > We welcome any constructive feedback. All input would be heard, and if the > > plans need to be amended, we will come back to you with the amended plan in > > a couple of weeks. This process will take some time and hopefully won't be > > too disruptive to anyone's usual workflow. > > What will be the process to bootstrap git? pkg install git comes to mind. -- Mathieu Arnold signature.asc Description: PGP signature
Re: [HEADS UP] Planned deprecation of portsnap
On Thu, Aug 06, 2020 at 01:57:41PM +0700, Eugene Grosbein wrote: > 06.08.2020 13:23, Doug Hardie wrote: > > >> On 5 August 2020, at 21:30, Eugene Grosbein wrote: > >> > >> 06.08.2020 6:02, Tatsuki Makino wrote > >> : > >>> Is there any command other than "rm -rf /usr/ports ; portsnap extract" > >>> that can be easily repaired? > >> > >> svnlite revert -R /usr/ports > > > > > > master# svnlite revert -R /usr/ports > > svn: E155007: '/usr/ports' is not a working copy > > master# > > master# rm -rf /usr/ports/* > > master# svnlite revert -R /usr/ports > > svn: E155007: '/usr/ports' is not a working copy > > If portsnap's deprecated, one uses "svnlite checkout" to replace portsnap's > data > with data of Subversion, then "svnlite revert" would work. Depending on the damage, you may also want to `svnlite cleanup --remove-unversioned` and maybe a plain rm -rf followed by a svnlite checkout. -- Mathieu Arnold signature.asc Description: PGP signature
Re: [HEADS UP] Planned deprecation of portsnap
> On 5 August 2020, at 23:57, Eugene Grosbein wrote: > > 06.08.2020 13:23, Doug Hardie wrote: > >>> On 5 August 2020, at 21:30, Eugene Grosbein wrote: >>> >>> 06.08.2020 6:02, Tatsuki Makino wrote >>> : >>>> Is there any command other than "rm -rf /usr/ports ; portsnap extract" >>>> that can be easily repaired? >>> >>> svnlite revert -R /usr/ports >> >> >> master# svnlite revert -R /usr/ports >> svn: E155007: '/usr/ports' is not a working copy >> master# >> master# rm -rf /usr/ports/* >> master# svnlite revert -R /usr/ports >> svn: E155007: '/usr/ports' is not a working copy > > If portsnap's deprecated, one uses "svnlite checkout" to replace portsnap's > data > with data of Subversion, then "svnlite revert" would work. > Thanks, -- Doug ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
06.08.2020 13:23, Doug Hardie wrote: >> On 5 August 2020, at 21:30, Eugene Grosbein wrote: >> >> 06.08.2020 6:02, Tatsuki Makino wrote >> : >>> Is there any command other than "rm -rf /usr/ports ; portsnap extract" >>> that can be easily repaired? >> >> svnlite revert -R /usr/ports > > > master# svnlite revert -R /usr/ports > svn: E155007: '/usr/ports' is not a working copy > master# > master# rm -rf /usr/ports/* > master# svnlite revert -R /usr/ports > svn: E155007: '/usr/ports' is not a working copy If portsnap's deprecated, one uses "svnlite checkout" to replace portsnap's data with data of Subversion, then "svnlite revert" would work. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
> On 5 August 2020, at 21:30, Eugene Grosbein wrote: > > 06.08.2020 6:02, Tatsuki Makino wrote > : >> Is there any command other than "rm -rf /usr/ports ; portsnap extract" >> that can be easily repaired? > > svnlite revert -R /usr/ports master# svnlite revert -R /usr/ports svn: E155007: '/usr/ports' is not a working copy master# master# rm -rf /usr/ports/* master# svnlite revert -R /usr/ports svn: E155007: '/usr/ports' is not a working copy -- Doug ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
06.08.2020 6:02, Tatsuki Makino wrote : > Is there any command other than "rm -rf /usr/ports ; portsnap extract" > that can be easily repaired? svnlite revert -R /usr/ports ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
Is there any command other than "rm -rf /usr/ports ; portsnap extract" that can be easily repaired? ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
from Hans Petter Selasky: > Maybe some silly questions already answered: > 1) portsnap is populating /usr/ports . Is this location still hardcoded > for ports tree installations, or can it be installed anywhere? > 2) Should portsnap be a wrapper for GIT/SVN whatever is used? > 3) Should /usr/ports be removed from any mtree files? > HPS Ports tree location is not hardcoded to /usr/ports. Because of multiple FreeBSD installations and wanting to install the ports tree redundantly, I have one /usr/ports and, from the other FreeBSD installations, use BETA1 as a mount point, so I get /BETA1/usr/ports. There was a bug beginning somewhere around FreeBSD 11.1 or 11.2, whereby running make (such as "make all-depends-list"), would be very messy if ports directory was not /usr/ports. I was able to create a workaround by setting MAKESYSPATH=/usr/share/mk (environment variable). Another workaround was to set ports directory to /usr/ports using a null mount. Tom ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
> On 4. Aug 2020, at 20:43, Steve Wills wrote: > > > We are planning to deprecate use of portsnap in ports. > > The reasons are as follows (in no particular order): > > * Portsnap doesn't support quarterly branches, even years after quarterly > branches were created and changed to the default for non-HEAD packages. > > * Portsnap doesn't seem to save disk space compared to svn or git, if you > count the metadata (stored in /var/db/portsnap by default) and you do an > apples-to-apples comparison of svn or git without history and ignoring > possible ZFS compression. That is, you use "svn export" or git "clone --depth > 1", you see this disk usage: > >342Msvnexport >426Mgit >477Mportsnap > > * Portsnap also doesn't work offline which git does. With git, you can also > easily add the history by running "git pull --unshallow" > > * This migration away from portsnap fits well with the planned migration to > git. > > * Also based on the patches we've seen in Bugzilla for some time, usage of > portsnap causes folks to too easily accidentally submit patches to Bugzilla > which don't apply easily. > > * Since portsnap doesn't support quarterly branches, it often causes users to > build on the wrong branch or end up with mismatched packages. That is, they > install packages from quarterly via pkg, then want to customize so run > portsnap and build from head, which can cause problems, as we often see. Even > when this doesn't happen, it adds to troubleshooting to verify that it didn't. > > We are aware people have gotten used to portsnap, but believe: > > * People should be able to easily use svnlite in base or git from pkgs. (Very > few people seem to actually use WITHOUT_SVNLITE). > > * There is also the possibility of falling back to fetching a tar or zip from > https://cgit-beta.freebsd.org/ports/ although this does make updating harder. > > How it will be done, in order: > > * Update poudriere to use svn by default. This is already done: > > https://github.com/freebsd/poudriere/pull/764 > https://github.com/freebsd/poudriere/commit/bd68f30654e2a8e965fbdc09aad238c8bf5cdc10 > > * Update docs not to mention portsnap. This is already in progress: > > https://reviews.freebsd.org/D25800 > https://reviews.freebsd.org/D25801 > https://reviews.freebsd.org/D25803 > https://reviews.freebsd.org/D25805 > https://reviews.freebsd.org/D25808 > https://svnweb.freebsd.org/changeset/base/363798 > > Many thanks to the folks who have worked and are working on this! > > * Make WITHOUT_PORTSNAP default in base. Currently not certain when this will > happen. May not happen before 13.0, but hopefully it will. > > * Eventually, portsnap servers will see low enough usage they can be disabled. > > We welcome any constructive feedback. All input would be heard, and if the > plans need to be amended, we will come back to you with the amended plan in a > couple of weeks. This process will take some time and hopefully won't be too > disruptive to anyone's usual workflow. What will be the process to bootstrap git? Thanks > > Steve (with portmgr@ hat) > ___ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
Hi, On 8/5/20 12:31 PM, Ernie Luzar wrote: I seems this is a done deal as changes are already being done now. So the real question is, when is the portsnap utility going to be removed from the base system? Will it happen in 12.2 or 13.0? Full removal may not happen before 13.0 but hopefully disabling it by default, so that it is not installed unless one explicitly enables it, will happen before 13.0. I maintain ports that use the portsnap utility. One is currently going through a maintenance cycle right now. Should the use of portsnap be removed from the port now? Not necessarily, as 11.x and 12.x will have it of course, but it should definitely handle portsnap not being present on the system in any case, since it can be disabled via WITHOUT_PORTSNAP (even on 11.x and 12.x). Steve ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
Steve Wills wrote: We are planning to deprecate use of portsnap in ports. The reasons are as follows (in no particular order): * Portsnap doesn't support quarterly branches, even years after quarterly branches were created and changed to the default for non-HEAD packages. * Portsnap doesn't seem to save disk space compared to svn or git, if you count the metadata (stored in /var/db/portsnap by default) and you do an apples-to-apples comparison of svn or git without history and ignoring possible ZFS compression. That is, you use "svn export" or git "clone --depth 1", you see this disk usage: 342Msvnexport 426Mgit 477Mportsnap * Portsnap also doesn't work offline which git does. With git, you can also easily add the history by running "git pull --unshallow" * This migration away from portsnap fits well with the planned migration to git. * Also based on the patches we've seen in Bugzilla for some time, usage of portsnap causes folks to too easily accidentally submit patches to Bugzilla which don't apply easily. * Since portsnap doesn't support quarterly branches, it often causes users to build on the wrong branch or end up with mismatched packages. That is, they install packages from quarterly via pkg, then want to customize so run portsnap and build from head, which can cause problems, as we often see. Even when this doesn't happen, it adds to troubleshooting to verify that it didn't. We are aware people have gotten used to portsnap, but believe: * People should be able to easily use svnlite in base or git from pkgs. (Very few people seem to actually use WITHOUT_SVNLITE). * There is also the possibility of falling back to fetching a tar or zip from https://cgit-beta.freebsd.org/ports/ although this does make updating harder. How it will be done, in order: * Update poudriere to use svn by default. This is already done: https://github.com/freebsd/poudriere/pull/764 https://github.com/freebsd/poudriere/commit/bd68f30654e2a8e965fbdc09aad238c8bf5cdc10 * Update docs not to mention portsnap. This is already in progress: https://reviews.freebsd.org/D25800 https://reviews.freebsd.org/D25801 https://reviews.freebsd.org/D25803 https://reviews.freebsd.org/D25805 https://reviews.freebsd.org/D25808 https://svnweb.freebsd.org/changeset/base/363798 Many thanks to the folks who have worked and are working on this! * Make WITHOUT_PORTSNAP default in base. Currently not certain when this will happen. May not happen before 13.0, but hopefully it will. * Eventually, portsnap servers will see low enough usage they can be disabled. We welcome any constructive feedback. All input would be heard, and if the plans need to be amended, we will come back to you with the amended plan in a couple of weeks. This process will take some time and hopefully won't be too disruptive to anyone's usual workflow. Steve (with portmgr@ hat) I seems this is a done deal as changes are already being done now. So the real question is, when is the portsnap utility going to be removed from the base system? Will it happen in 12.2 or 13.0? I maintain ports that use the portsnap utility. One is currently going through a maintenance cycle right now. Should the use of portsnap be removed from the port now? ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Git migration - was Re: [HEADS UP] Planned deprecation of portsnap
Hi, On 8/5/20 5:42 AM, Yasuhiro KIMURA wrote: From: Kurt Jaeger Subject: Re: [HEADS UP] Planned deprecation of portsnap Date: Wed, 5 Aug 2020 06:40:39 +0200 There's a list where the git topic is discussed: https://lists.freebsd.org/pipermail/freebsd-git/ Have a look at the archive, and yes, subversion as version control system for the FreeBSD project will probably be replaced by git. It's a bit hard for me to read entire archive;-). So is there summary of git migration project (about purpose, plan, current status, etc)? Can we please keep the discussion about git in a different thread, I'm trying to monitor the portsnap related thread for issues related to that. Thanks, Steve ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
On Wed, Aug 05, 2020 at 12:40:26PM +0100, Bob Eager wrote: > On Wed, 5 Aug 2020 13:32:10 +0200 > Mathieu Arnold wrote: > > > On Wed, Aug 05, 2020 at 12:59:18PM +0200, Hans Petter Selasky wrote: > > > On 2020-08-04 20:43, Steve Wills wrote: > > > > > > > > We are planning to deprecate use of portsnap in ports. > > > > > > > > The reasons are as follows (in no particular order): > > > > > > > > * Portsnap doesn't support quarterly branches, even years after > > > > quarterly branches were created and changed to the default for > > > > non-HEAD packages. > > > > > > Hi, > > > > > > Maybe some silly questions already answered: > > > > > > 1) portsnap is populating /usr/ports . Is this location still > > > hardcoded for ports tree installations, or can it be installed > > > anywhere? > > > > > > 3) Should /usr/ports be removed from any mtree files? > > > > The default location for the ports tree is taken from the PORTSDIR > > environment variable, and it defaults to /usr/ports. > > > > Is that true for installation __of the tree__, as asked? If so, how is > it set? Well, portsnap has a default value hardcoded, otherwise, the value is taken from /usr/share/mk, like most default values. -- Mathieu Arnold signature.asc Description: PGP signature
Re: [HEADS UP] Planned deprecation of portsnap
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, 5 Aug 2020 13:32:10 +0200 Mathieu Arnold wrote: > On Wed, Aug 05, 2020 at 12:59:18PM +0200, Hans Petter Selasky wrote: > > On 2020-08-04 20:43, Steve Wills wrote: > > > > > > We are planning to deprecate use of portsnap in ports. > > > > > > The reasons are as follows (in no particular order): > > > > > > * Portsnap doesn't support quarterly branches, even years after > > > quarterly branches were created and changed to the default for > > > non-HEAD packages. > > > > Hi, > > > > Maybe some silly questions already answered: > > > > 1) portsnap is populating /usr/ports . Is this location still > > hardcoded for ports tree installations, or can it be installed > > anywhere? > > > > 3) Should /usr/ports be removed from any mtree files? > > The default location for the ports tree is taken from the PORTSDIR > environment variable, and it defaults to /usr/ports. > Is that true for installation __of the tree__, as asked? If so, how is it set? -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEVgdI2KeVldPAhUYaKBdf2az8e6gFAl8qmqoACgkQKBdf2az8 e6g0pQf+L9aDM8tPzxdYS43IHGbC9LmL4qrQayzXZCheZHTw7yUgZjwppE24u49f smKVsNSYjvAtP7ZOow8tIascxis2+bNO29MSj2Id7jlIxsR4SeLQTgExf6fxqepi y2kllhfc5lv4RqUScnDE02vWbgwc0CVCSO4kHl7rJp3FB3ebbb9vC2HmSeBEtYcF Vv1GJWZz08AbHwgeBOk4XCiMy+rCGd+Ewmv6PriQftiX/UG1ogvcz1XRLASFAW5T 1b2Qak6habvM7iskBXcUbzZrDCHoJelDQtLOCuZQx3OBWRwq1U7j43E7KwTzxU3e thPsGv/6WLRp9179bkziBLoKx0uPYg== =B+nJ -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
On Wed, Aug 05, 2020 at 12:59:18PM +0200, Hans Petter Selasky wrote: > On 2020-08-04 20:43, Steve Wills wrote: > > > > We are planning to deprecate use of portsnap in ports. > > > > The reasons are as follows (in no particular order): > > > > * Portsnap doesn't support quarterly branches, even years after > > quarterly branches were created and changed to the default for non-HEAD > > packages. > > Hi, > > Maybe some silly questions already answered: > > 1) portsnap is populating /usr/ports . Is this location still hardcoded for > ports tree installations, or can it be installed anywhere? > > 3) Should /usr/ports be removed from any mtree files? The default location for the ports tree is taken from the PORTSDIR environment variable, and it defaults to /usr/ports. -- Mathieu Arnold signature.asc Description: PGP signature
Re: [HEADS UP] Planned deprecation of portsnap
On 2020-08-04 20:43, Steve Wills wrote: We are planning to deprecate use of portsnap in ports. The reasons are as follows (in no particular order): * Portsnap doesn't support quarterly branches, even years after quarterly branches were created and changed to the default for non-HEAD packages. Hi, Maybe some silly questions already answered: 1) portsnap is populating /usr/ports . Is this location still hardcoded for ports tree installations, or can it be installed anywhere? 2) Should portsnap be a wrapper for GIT/SVN whatever is used? 3) Should /usr/ports be removed from any mtree files? --HPS ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
From: Kurt Jaeger Subject: Re: [HEADS UP] Planned deprecation of portsnap Date: Wed, 5 Aug 2020 06:40:39 +0200 > There's a list where the git topic is discussed: > > https://lists.freebsd.org/pipermail/freebsd-git/ > > Have a look at the archive, and yes, subversion as version control > system for the FreeBSD project will probably be replaced by git. It's a bit hard for me to read entire archive;-). So is there summary of git migration project (about purpose, plan, current status, etc)? --- Yasuhiro KIMURA ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
On Tue, Aug 04, 2020 at 09:51:23PM -0700, Chris wrote: > This is very bad news for us. I can make so many arguments against > dropping subversion. It's really not (needn't be) a matter of either/or. In this sentence, who is "us"? Also, can you elaborate? -- Mathieu Arnold signature.asc Description: PGP signature
Re: [HEADS UP] Planned deprecation of portsnap
On Tue, 04 Aug 2020 19:03:08 -0700 Chris wrote: > Please tell me that this doesn't mean a > > [HEADS UP] Planned deprecation of subversion > > is on the horizon. I'm afraid that git is fashionable now. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
Hi! > > > > * This migration away from portsnap fits well with the planned > > > > migration to git. > > Have a look at the archive, and yes, subversion as version control > > system for the FreeBSD project will probably be replaced by git. > This is very bad news for us. I can make so many arguments against > dropping subversion. It's really not (needn't be) a matter of either/or. Can you elaborate on those arguments ? Maybe if you first review those that were mentioned on the git list in the past ? -- p...@opsec.eu+49 171 3101372Now what ? ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
On Wed, 5 Aug 2020 06:40:39 +0200 Kurt Jaeger p...@freebsd.org said Hi! > > * This migration away from portsnap fits well with the planned > > migration to git. > Please tell me that this doesn't mean a > > [HEADS UP] Planned deprecation of subversion > > is on the horizon. There's a list where the git topic is discussed: https://lists.freebsd.org/pipermail/freebsd-git/ Have a look at the archive, and yes, subversion as version control system for the FreeBSD project will probably be replaced by git. Thank you very much for taking the time to respond, Kurt! :-) This is very bad news for us. I can make so many arguments against dropping subversion. It's really not (needn't be) a matter of either/or. Thanks again, Kurt. Even if it wasn't what I wanted to hear. --Chris ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
Hi! > > * This migration away from portsnap fits well with the planned > > migration to git. > Please tell me that this doesn't mean a > > [HEADS UP] Planned deprecation of subversion > > is on the horizon. There's a list where the git topic is discussed: https://lists.freebsd.org/pipermail/freebsd-git/ Have a look at the archive, and yes, subversion as version control system for the FreeBSD project will probably be replaced by git. -- p...@opsec.eu+49 171 3101372Now what ? ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Planned deprecation of portsnap
On Tue, 4 Aug 2020 14:43:20 -0400 Steve Wills swi...@freebsd.org said We are planning to deprecate use of portsnap in ports. ... Makes sense to me. Thank you. :-) * Portsnap doesn't seem to save disk space compared to svn or git, if you count the metadata (stored in /var/db/portsnap by default) and you do an apples-to-apples comparison of svn or git without history and ignoring possible ZFS compression. That is, you use "svn export" or git "clone --depth 1", you see this disk usage: 342Msvnexport 426Mgit 477Mportsnap * Portsnap also doesn't work offline which git does. With git, you can also easily add the history by running "git pull --unshallow" * This migration away from portsnap fits well with the planned migration to git. Please tell me that this doesn't mean a [HEADS UP] Planned deprecation of subversion is on the horizon. --Chris ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
[HEADS UP] Planned deprecation of portsnap
We are planning to deprecate use of portsnap in ports. The reasons are as follows (in no particular order): * Portsnap doesn't support quarterly branches, even years after quarterly branches were created and changed to the default for non-HEAD packages. * Portsnap doesn't seem to save disk space compared to svn or git, if you count the metadata (stored in /var/db/portsnap by default) and you do an apples-to-apples comparison of svn or git without history and ignoring possible ZFS compression. That is, you use "svn export" or git "clone --depth 1", you see this disk usage: 342Msvnexport 426Mgit 477Mportsnap * Portsnap also doesn't work offline which git does. With git, you can also easily add the history by running "git pull --unshallow" * This migration away from portsnap fits well with the planned migration to git. * Also based on the patches we've seen in Bugzilla for some time, usage of portsnap causes folks to too easily accidentally submit patches to Bugzilla which don't apply easily. * Since portsnap doesn't support quarterly branches, it often causes users to build on the wrong branch or end up with mismatched packages. That is, they install packages from quarterly via pkg, then want to customize so run portsnap and build from head, which can cause problems, as we often see. Even when this doesn't happen, it adds to troubleshooting to verify that it didn't. We are aware people have gotten used to portsnap, but believe: * People should be able to easily use svnlite in base or git from pkgs. (Very few people seem to actually use WITHOUT_SVNLITE). * There is also the possibility of falling back to fetching a tar or zip from https://cgit-beta.freebsd.org/ports/ although this does make updating harder. How it will be done, in order: * Update poudriere to use svn by default. This is already done: https://github.com/freebsd/poudriere/pull/764 https://github.com/freebsd/poudriere/commit/bd68f30654e2a8e965fbdc09aad238c8bf5cdc10 * Update docs not to mention portsnap. This is already in progress: https://reviews.freebsd.org/D25800 https://reviews.freebsd.org/D25801 https://reviews.freebsd.org/D25803 https://reviews.freebsd.org/D25805 https://reviews.freebsd.org/D25808 https://svnweb.freebsd.org/changeset/base/363798 Many thanks to the folks who have worked and are working on this! * Make WITHOUT_PORTSNAP default in base. Currently not certain when this will happen. May not happen before 13.0, but hopefully it will. * Eventually, portsnap servers will see low enough usage they can be disabled. We welcome any constructive feedback. All input would be heard, and if the plans need to be amended, we will come back to you with the amended plan in a couple of weeks. This process will take some time and hopefully won't be too disruptive to anyone's usual workflow. Steve (with portmgr@ hat) ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: portsnap broken?
On Wed, Jul 03, 2019 at 10:11:41AM +0200 I heard the voice of
Kurt Jaeger, and lo! it spake thus:
>
> > With a little script to pull the snapdates:
> > [...]
>
> Nice! Can you put that script somewhere for others to use ?
It's pretty small and straightforward. Attached. It _is_ based on a
bit of reverse-engineering of /usr/sbin/portsnap, so there may well be
a better way already extant of getting the info (and there probably
should be, if there isn't), but it Works For Me...
#!/usr/bin/env perl
use strict;
use warnings;
# Find the server list
my @servers;
{
use Net::DNS;
my $res = Net::DNS::Resolver->new;
my $srv = $res->search('_http._tcp.portsnap.freebsd.org', 'SRV');
die "Nothing from SRV request: @{[$res->errorstring]}\n" unless $srv;
foreach my $rr (grep { $_->type eq 'SRV' } $srv->answer)
{
my $si = {
'priority' => $rr->priority,
'host' => $rr->target,
};
push @servers, $si;
}
@servers = sort {
my $r;
return $r if($r = ($a->{priority} <=> $b->{priority}));
return $r if($r = ($a->{host} cmp $b->{host}));
return 0;
} @servers;
}
# We need to store temp files to go through openssl...
my $tmpdir;
{
use File::Temp qw/tempdir/;
$tmpdir = tempdir(CLEANUP => 1);
die "Failed making tempdir" unless -d $tmpdir;
}
# Load snapshot info and check timestamp from each
for my $s (@servers)
{
my $host = $s->{host};
my $key = "http://$host/pub.ssl;;
my $snap = "http://$host/latest.ssl;;
my $keyout = "$tmpdir/$host.key";
my $snapout = "$tmpdir/$host.snap";
use LWP::UserAgent;
my $web = LWP::UserAgent->new(timeout => 5);
my $res = $web->get($key, ':content_file' => $keyout);
if(!$res->is_success)
{
$s->{failed} = 1;
print STDERR "$host key fetch failed: @{[$res->status_line]}\n";
next;
}
$res = $web->get($snap, ':content_file' => $snapout);
if(!$res->is_success)
{
$s->{failed} = 1;
print STDERR "$host snap fetch failed:
@{[$res->status_line]}\n";
next;
}
# Now we use openssl to dissect
my @cmd = ( qw(openssl rsautl -pubin -inkey), $keyout, '-verify' );
use IPC::Run3;
my ($out, $err);
run3(\@cmd, $snapout, \$out, \$err);
my $rc = $? >> 8;
if($rc != 0)
{
$s->{failed} = 1;
print STDERR "$host: openssl returned $rc\n$err\n";
next;
}
# Second field of $out is the timestamp
chomp $out;
my $ts = (split/\|/, $out)[1];
$s->{timestamp} = $ts;
}
# And show the results
my $now = time;
for my $s (@servers)
{
my $host = $s->{host};
(my $sh = $host) =~ s/\.portsnap\.freebsd\.org$//;
if($s->{failed})
{
print "$sh: failed\n";
next;
}
my $pri = $s->{priority};
my $ts = $s->{timestamp};
# How old?
my $old = $now - $ts;
my $age;
if($old > 86400)
{
my $days = int($old / 86400);
$age .= "$days days, ";
$old -= ($days * 86400);
}
{
my $hours = int($old / 3600);
$old -= ($hours * 3600);
my $mins = int($old / 60);
$old -= ($mins * 60);
$age .= sprintf("%02d:%02d:%02d", $hours, $mins, $old);
}
use Date::Format;
chomp(my $ftime = ctime($ts));
printf "%20s: $ftime ($age ago)\n", $sh;
}
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: portsnap broken?
> Any ideas when this will be fixed ? > Looks like it's fixed now. -- Ashish SHUKLA | GPG: F682CDCC39DC0FEAE11620B6C746CFA9E74FA4B0 “We are drowning in information but starved for knowledge.” (John Naisbitt, "Megatrends") signature.asc Description: OpenPGP digital signature
Re: Portsnap broke?
Yes, looks like it is broken. For me doesn't works from yesterday morning. -- “Happiness is the meaning and the purpose of life, the whole aim and end of human existence.” ― Aristotle ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: portsnap broken?
On 7/3/19 7:15 AM, @lbutlr wrote:
> On 2 Jul 2019, at 18:33, Ashish SHUKLA wrote:
>> I noticed portsnap mirror is outdated for few hours now:
>
> Out of date based on what? How often are you pulling portsnap?
>
> (I run portsnap cron update once a day)
I pull few times a day, and it's usually refreshed with-in few hours, as
least for past few years. And the original message I posted was after ~5
minutes ago from my most recent fetch.
--
Ashish SHUKLA | GPG: F682CDCC39DC0FEAE11620B6C746CFA9E74FA4B0
“As far as the laws of mathematics refer to reality, they are not
certain; and as far as they are certain, they do not refer to reality.”
("Albert Einstein", "Sidelights on Relativity", 1983)
signature.asc
Description: OpenPGP digital signature
Re: portsnap broken?
On Tue, Jul 02, 2019 at 07:45:26PM -0600 I heard the voice of @lbutlr, and lo! it spake thus: > > Out of date based on what? How often are you pulling portsnap? With a little script to pull the snapdates: % ./psinfo.pl your-org: Sun Jun 30 19:26:35 2019 (2 days, 01:24:42 ago) metapeer: Sun Jun 30 19:26:35 2019 (2 days, 01:24:42 ago) ec2-eu-west-1: Sun Jun 30 19:26:35 2019 (2 days, 01:24:42 ago) ec2-ap-southeast-2: Sun Jun 30 19:26:35 2019 (2 days, 01:24:42 ago) ec2-ap-northeast-1: Sun Jun 30 19:26:35 2019 (2 days, 01:24:42 ago) ec2-sa-east-1: Sun Jun 30 19:26:35 2019 (2 days, 01:24:42 ago) -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: portsnap broken?
On 2 Jul 2019, at 18:33, Ashish SHUKLA wrote: > I noticed portsnap mirror is outdated for few hours now: Out of date based on what? How often are you pulling portsnap? (I run portsnap cron update once a day) -- THEY ARE LAUGHING AT ME, NOT WITH ME Bart chalkboard Ep. 7G12 ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
portsnap broken?
Hi, I noticed portsnap mirror is outdated for few hours now: λ sudo make -C /usr/ports update Password: -- >>> Running portsnap -- Looking up portsnap.FreeBSD.org mirrors... 6 mirrors found. Fetching snapshot tag from ec2-ap-southeast-2.portsnap.freebsd.org... done. Latest snapshot on server matches what we already have. No updates needed. Ports tree is already up to date. λ make -C /usr/ports/finance/gnucash -V PKGNAME gnucash-3.5_2 The port was last updated in r505667 to 3.6 at July 02, 2019 08:18 UTC. Any ideas when this will be fixed ? Thanks! -- Ashish SHUKLA | GPG: F682CDCC39DC0FEAE11620B6C746CFA9E74FA4B0 “The English have no respect for their language, and will not teach their children to speak it.” (George Bernard Shaw, "Pygmalion", 1912) signature.asc Description: OpenPGP digital signature
Re: portsnap update
"Alex V. Petrov" writes: > How often should the portsnap database be updated? > Why is it not updated a long time sometimes? > > Now: > Updating from Tue Aug 21 12:22:20 +07 2018 to Wed Aug 22 02:34:43 +07 2018. Fourteen hours? I do not think of that as "a long time." ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
portsnap update
How often should the portsnap database be updated? Why is it not updated a long time sometimes? Now: Updating from Tue Aug 21 12:22:20 +07 2018 to Wed Aug 22 02:34:43 +07 2018. -- - Alex. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: portsnap not honoring WORKDIR and PORTSDIR?
On Sat, 21 Apr 2018 16:49:13 -0600
Gary Aitken wrote:
> Is portsnap supposed to honor WORKDIR and PORTSDIR?
>
> These are defined in /etc/portsnap.conf, and it's not clear to me
> whether they are honored only via the .conf file or whether they
> are supposed to be honored from the environment as well.
>
> They appear to not be honored from the environment, and I'm wondering
> whether that is deliberate or an oversight that should be corrected.
>
It's deliberate:
# Initialize parameters to null, just in case they're
# set in the environment.
init_params() {
KEYPRINT=""
EXTRACTPATH=""
WORKDIR=""
PORTSDIR=""
...
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
portsnap not honoring WORKDIR and PORTSDIR?
Is portsnap supposed to honor WORKDIR and PORTSDIR? These are defined in /etc/portsnap.conf, and it's not clear to me whether they are honored only via the .conf file or whether they are supposed to be honored from the environment as well. They appear to not be honored from the environment, and I'm wondering whether that is deliberate or an oversight that should be corrected. Thanks, Gary ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Do I need /var/db/portsnap/distfiles and /usr/port/distfiles?
On Thu, 16 Feb 2017, RW via freebsd-ports wrote: > > aneurin# du -sk /usr/ports/distfiles /var/db/portsnap/files > > 965198 /usr/ports/distfiles > > This is a cache, so you can delete it, or trim it with distclean > (installed with portupgrade), or portmaster. Thanks; nearly 1GB here I come... > > 106594 /var/db/portsnap/files > > If you don't use portsnap then you can delete everything under > /var/db/portsnap. Don't delete these files if you do. Yes, I do use portsnap, so thanks for the advice. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Do I need /var/db/portsnap/distfiles and /usr/port/distfiles?
On Fri, 17 Feb 2017 08:32:17 +1100 (EST) Dave Horsfall wrote: > There is only the one FreeBSD box in my stable, hence I don't need to > build packages for others. It's to to do with whether you use ports, rather than if you build package for other boxes. > It's a somewhat minimalist box (all I can > afford), and I'd like to recover some space. Can I just delete their > contents? > > aneurin# du -sk /usr/ports/distfiles /var/db/portsnap/files > 965198/usr/ports/distfiles This is a cache, so you can delete it, or trim it with distclean (installed with portupgrade), or portmaster. > 106594/var/db/portsnap/files If you don't use portsnap then you can delete everything under /var/db/portsnap. Don't delete these files if you do. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: portsnap temporary files
Sigh... It seems those files were needed after all, as they must refer to the current system; chalk it up to my lack of understanding of how "portsnap" works. I got them back (plus more besides) from a backup on my MacBook. What freaked me out was actually looking at the list of files being backed up, and thought the worst. And the sooner I upgrade to FreeBSD-10 the better, I think. Sorry for wasting everyone's time... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: portsnap temporary files
On Sat, 7 Jan 2017 06:51:44 +1100 (EST) Dave Horsfall wrote: > Is there some reason why portsnap cannot clean > up /var/db/portsnap/files? I've just had to remove a zillion of them, > a bunch at a time because "rm" choked on the arg list. If you mean files under /var/db/portsnap/files/ then these are not temporary files, they are the compressed snapshot, and you should not delete them without very good reason. They are supposed to persist and may remain unmodified for many months. Zillion is a bit vague, there should be one file for each port plus one for each file outside a port directory. I have ~27k files. The temporary .gz files are stored in the directory above and may be deleted. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
