Date: Sat, 9 Nov 2019 16:45:07 -0800 From: Craig Leres <leres@freebsd.org> To: Mathieu Arnold <mat@FreeBSD.org> Cc: Antoine Brodin <antoine@freebsd.org>, ports-committers <ports-committers@freebsd.org>, svn-ports-all <svn-ports-all@freebsd.org>, svn-ports-head <svn-ports-head@freebsd.org> Subject: Re: svn commit: r516880 - in head: archivers/xarchiver astro/garmindev astro/opencpn astro/qmapshack audio/carla audio/decibel-audio-player audio/festvox-czech audio/gkrellmvolume2 audio/gnaural audio/... Message-ID: <002a81a3-babd-f176-19cb-af7a54b303e8@freebsd.org> In-Reply-To: <20191109101904.gdujuxypgohzmet6@atuin.in.mat.cc> References: <201911061248.xA6CmWBf088616@repo.freebsd.org> <96e1675e-d1e6-251c-4290-228a8ceaad1c@freebsd.org> <CAALwa8kXqS9rEH5=6bB3A%2BsjSJ_68NVVtskEivmpTim2J3vjjw@mail.gmail.com> <c7fd2bcf-1650-b81d-fcec-f9fbd4107fa8@freebsd.org> <20191109101904.gdujuxypgohzmet6@atuin.in.mat.cc>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2019-11-09 02:19, Mathieu Arnold wrote: > On Fri, Nov 08, 2019 at 04:20:59PM -0800, Craig Leres wrote: >> On 2019-11-08 14:02, Antoine Brodin wrote: >>> On Fri, Nov 8, 2019 at 8:40 PM Craig Leres <leres@freebsd.org> wrote: >>>> >>>> On 2019-11-06 04:48, Antoine Brodin wrote: >>>>> Author: antoine >>>>> Date: Wed Nov 6 12:48:32 2019 >>>>> New Revision: 516880 >>>>> URL: https://svnweb.freebsd.org/changeset/ports/516880 >>>>> >>>>> Log: >>>>> Mark a few ports BROKEN, unfetchable >>>>> >>>>> Modified: >>>> >>>>> head/devel/xtensa-esp32-elf/Makefile >>>> >>>> I just did: >>>> >>>> cd devel/xtensa-esp32-elf >>>> rm distinfo >>>> make makesum >>>> >>>> and was able to download all of the DISTFILES again and generate a new >>>> distinfo that is identical except for the TIMESTAMP line. >>>> >>>> What identified this port as unfetchable? >>> >>> You must be joking. >> >> (That's not very friendly or helpful!) > > Well, the thing is, portmgr's job is not to fix all the ports, it is to > curate the ports tree. It means that when something is broken, we don't > try to look at why. We mark it broken and let the community fix it. > > Also, we only mark ports as being broken because they are not fetchable > after about six months of them not being fetchable. I guess my point is if port maintainers could be notified when a port becomes unfetchable it would give them time to fix the problem. (Perhaps six months?) Consider that users of the port will have a local copy of the DISTFILES that work in /usr/ports/distfiles. So if something happens with individual MASTER_SITES we're not going to notice. > And each time, people who should know better assume that we're dumb and > are in error because while they should know how the ports tree work, > they figure they know better than us and we're wrong. > > So, yeah, from time to time, especially after it's the fifth time in > like two days that someone tells us "you're doing shit" while being > clueless, it happens that we're not as patient as we could be. I'm 200% sure I didn't tell anybody "you're doing shit". I asked what how the port was selected and this was (eventually) explained. But who runs this process? How often does it happen? For example you marked net-mgmt/telegraf as BROKEN/unfetchable. But I just ran "make checksum DISTDIR=/tmp" and was able to re-download all 146 files in distinfo. So while I'd like to port to be buildable again I'm not sure I understand what is wrong with it. Was a temporary server problem? Is it fetchable/not-fetchable depending on where you try to download it? Was it just a mistake? Meanwhile I'll ask again: is possible to get advance warning about unfetchable probelms? It sounds like portscout should do it or used to do it. How do you generate the list of BROKEN/unfetchable? Is it just adhoc or is there a process that systematically identifies candidates? Please understand I'm not complaining, just trying to understand how I can do a better job and avoid having ports that are important to me broken at inconvenient times. Craig
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?002a81a3-babd-f176-19cb-af7a54b303e8>