Compradores profesionales - Cómo ser el mejor
¿Requiere la información a la brevedad? , responda este email con la palabra Comprador. Centro telefónico: 018002129393. Usted podrá cursar esta capacitación ONLINE en Vivo desde la comodidad de su casa u oficina con todas las ventajas que le ofrece un curso presencial de manera remota, ¡y en tiempo real! Cómo ser el mejor COMPRADOR Actualización para compradores profesionales TEMARIO: 1. Técnicas de predicción. 2. Las necesidades de la empresa. 3. Evaluación de proveedores. 4. ¿Qué se puede negociar? 5. El costo del dinero. 25 de mayo - Online en Vivo - 10:00 a 13:00 y de 15:00 a 18:00Hrs Identifique como establecer las metas y los objetivos reales de compras, obtener mayor productividad en su trabajo, apoyar la planeación del inventario, escoger mejores sistemas de entrega y hacer una programación adecuada con sus proveedores. Dirigido a: Jefes de compras y materiales, Gerentes administrativos, Compradores incluyendo Secretarias, Asistentes y todas las personas interesadas en aprender a trabajar más exitosamente con los proveedores y que quieren llegar a ser más hábiles para comprar mercancías. Lic. Diana López Líder de Proyectos Nuevas póliza de Capacitación • Área Contabilidad y Finanzas • 12 temas, 3 meses, 7 días a la semana, 24 horas al día • Precio Especial solo en Mayo • ¿Demasiados mensajes en su cuenta? Responda este mensaje indicando que solo desea recibir CALENDARIO y sólo recibirá un correo al mes. Si desea cancelar la suscripción, solicite su BAJA. ___ 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: databases/mariadb100-client fails to compile
An other way is: make -DWITH_OPENSSL_PORT ___ 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: databases/mariadb100-client fails to compile
I commented out the line
-DWITH_SSL=${OPENSSLBASE}
in mariadb100-server/Makefile
and it compiles fine.
___
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: Poudriere question
On Tue, 10 May 2016 17:05:20 +0200 Guido Falsi wrote: > Never seen poudriere remove distfiles, nor the ports tree do that, > what change are you referring to? > The problem isn't anything to do with poudriere. It was caused by a change to the checksum target in ports. The checksum of a pre-existing file is tested and if it fails, the file is deleted and a new version is downloaded. The point of this is presumably to remove re-rolled distfiles. The problem is that a file that fails the checksum is usually either a useful incomplete file from an interrupted download, or a download in progress. ___ 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: Poudriere question
On 05/10/16 16:25, RW via freebsd-ports wrote: > On Tue, 10 May 2016 14:35:35 +0200 > Guido Falsi wrote: > >> On 05/10/16 13:35, RW via freebsd-ports wrote: >>> On Mon, 9 May 2016 20:15:12 +0200 >>> Guido Falsi wrote: >>> On 05/09/16 19:52, Fernando Apesteguía wrote: > Hi all, > > Is it safe to use different invocations of poudriere concurrently > for different jails but using the same ports collection? > Yes it is, or at least should be. The ports trees are mounted read only in the jails, the wrkdir is defined at a different path. >>> >>> What about the distfiles directory? >>> >>> Having two "make checksums" running on the same file used to work >>> fairly well, but not any more because the target now deletes an >>> incomplete file rather than trying to resume it. >>> >>> This wont damage packages, but it can cause two "make checksums" to >>> get locked in a cycle of deleting each other's files and end w >>> one getting a failed checksum. >> >> Yes it happens, I even have used the same disfiles over NFS with more >> than one machine/poudriere accessing it. >> >> The various instances do overwrite each other and checksums do fail >> but usually in the end one of them "wins" and the correct file ends >> up being completed, with other instances reading that one. I agree >> this happens just by chance and not due to good design. > > Only the last process will terminate with a complete file and without > error, when another process runs out of retries, the file with the > directory entry is a download in progress which will fail the checksum. > > If it commonly ends-up working in poudriere that's probably a property > of how poudriere orders things. But you still have the problem of > wasted time and bandwidth. This problem is most likely with large > distfiles and there's at least one that's 1 GB. As I said, yes this ends up working by chance most of the time, and not without the problems you note. My comment was just stating the situation, I don't have a solution, but if you have an idea you can propose patches to poudriere. Sharing distfiles directory between processes is anyway "racy" in itself. Any way to "fix" this that comes to my mind would require adding special knowledge about the distfiles directory working in the poudriere process or the jails, which beats some design principles behind poudriere. > > > The way this used to work is that the second process would try to > resume the download which presumably involved getting a lock on the > file. For smaller files it would just work. Worst case was that the > second process would fail after a timeout. It all depends on what you are trying to obtain/doing. In my case I had at most 3-4 simultaneous accesses and since it "mostly worked" I never investigated it more. If you need high concurrency you need to work out some other solution. The distfile cache system has never been designed with concurrency in mind. One possible solution is not using a distfile cache for the jails making each jail have it's own and leverage MASTER_SITE_OVERRIDE to point to a local server which acts as a cache. Then one needs a way to sync things back to that machine after a successful download. Poudriere hooks come to my mind, but there isn't one for "post-fetch". > > I think the change came in to delete possible re-rolled distfiles > automatically (a relatively minor problem), but in the process it > created this problem and also broke resuming downloads. > > I don't see the reason for checking and deleting the file before > attempting to resume it. Never seen poudriere remove distfiles, nor the ports tree do that, what change are you referring to? -- Guido Falsi ___ 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: graphics/ImageMagick vulnerability status?
Really doesn't help that they keep revising the fix, 3 releases in 6 days, latest version actually being 6.9.4-1 :( On 10/05/2016 15:09, Stefan Bethke wrote: Hey, according to https://www.imagemagick.org/discourse-server/viewtopic.php?f=4&t=29588, a release 6.9.4-0 should be out that improves the situation significantly. It appears that graphics/ImageMagick is at 6.9.3. It would be nice if people who follow ImageMagick more closely than me could speak to the security status of the current port, updates planned, and/or additional mitigation recommended. Heise News is reporting that exploits have been posted and are seen in the wild. Thanks, 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: Poudriere question
On Tue, 10 May 2016 14:35:35 +0200 Guido Falsi wrote: > On 05/10/16 13:35, RW via freebsd-ports wrote: > > On Mon, 9 May 2016 20:15:12 +0200 > > Guido Falsi wrote: > > > >> On 05/09/16 19:52, Fernando Apesteguía wrote: > >>> Hi all, > >>> > >>> Is it safe to use different invocations of poudriere concurrently > >>> for different jails but using the same ports collection? > >>> > >> > >> Yes it is, or at least should be. > >> > >> The ports trees are mounted read only in the jails, the wrkdir is > >> defined at a different path. > > > > What about the distfiles directory? > > > > Having two "make checksums" running on the same file used to work > > fairly well, but not any more because the target now deletes an > > incomplete file rather than trying to resume it. > > > > This wont damage packages, but it can cause two "make checksums" to > > get locked in a cycle of deleting each other's files and end w > > one getting a failed checksum. > > Yes it happens, I even have used the same disfiles over NFS with more > than one machine/poudriere accessing it. > > The various instances do overwrite each other and checksums do fail > but usually in the end one of them "wins" and the correct file ends > up being completed, with other instances reading that one. I agree > this happens just by chance and not due to good design. Only the last process will terminate with a complete file and without error, when another process runs out of retries, the file with the directory entry is a download in progress which will fail the checksum. If it commonly ends-up working in poudriere that's probably a property of how poudriere orders things. But you still have the problem of wasted time and bandwidth. This problem is most likely with large distfiles and there's at least one that's 1 GB. The way this used to work is that the second process would try to resume the download which presumably involved getting a lock on the file. For smaller files it would just work. Worst case was that the second process would fail after a timeout. I think the change came in to delete possible re-rolled distfiles automatically (a relatively minor problem), but in the process it created this problem and also broke resuming downloads. I don't see the reason for checking and deleting the file before attempting to resume it. > As far as I understand Unix Filesystem semantics each download > actually creates a new file, with only the last one to start > referencing the actual file visible on the filesystem. So the last > one starting to download is the one which will "win" creating the > correct file on the FS, then checksumming it and going on. The other > files have actuay been deleted and are simply removed from disk as > soon as the download ends, if at that point the "winning" one has > finished the download, they will checksum that file. > > There is a chance of the loosing download to end before the winning > one ends and overwriting it again, but in my experience with at most > 3-4 instances over NFS it usually fixes itself in the long run. > > IMHO best solution is to make sure you already have distfiles on disk > for what you are going to build. > ___ 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: what for is the "gogs" UID/GID
On Wed, May 4, 2016 at 2:58 AM, Matthias Fechner wrote: > if you have something to test, please let me know. > Currently the fetch process seems not to work and the initial author of > the patch has no time to continue here. > > Some patches seems to have been refused (205032)... > > I can help you with testing, I have an older version of gogs here running, > but it stopped as I described in PR 205283. > I started playing with the port, but could not get it to work even after chasing the dependencies. I also tried mimicking the influxdb port, which uses lots of github resources to build a go project, but there is something just not letting it work to fetch all the distfiles. I have no clue why it works for influxdb but not gogs. I ended up manually building and installing it, and wrote a custom rc.d script since the one from the proposed port was way overly complex. I posted my notes on the gogs forum: https://discuss.gogs.io/t/installing-on-freebsd-10/331 ___ 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"
graphics/ImageMagick vulnerability status?
Hey, according to https://www.imagemagick.org/discourse-server/viewtopic.php?f=4&t=29588, a release 6.9.4-0 should be out that improves the situation significantly. It appears that graphics/ImageMagick is at 6.9.3. It would be nice if people who follow ImageMagick more closely than me could speak to the security status of the current port, updates planned, and/or additional mitigation recommended. Heise News is reporting that exploits have been posted and are seen in the wild. Thanks, Stefan -- Stefan BethkeFon +49 151 14070811 ___ 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: Poudriere question
On 05/10/16 13:35, RW via freebsd-ports wrote: > On Mon, 9 May 2016 20:15:12 +0200 > Guido Falsi wrote: > >> On 05/09/16 19:52, Fernando Apesteguía wrote: >>> Hi all, >>> >>> Is it safe to use different invocations of poudriere concurrently >>> for different jails but using the same ports collection? >>> >> >> Yes it is, or at least should be. >> >> The ports trees are mounted read only in the jails, the wrkdir is >> defined at a different path. > > What about the distfiles directory? > > Having two "make checksums" running on the same file used to work > fairly well, but not any more because the target now deletes an > incomplete file rather than trying to resume it. > > This wont damage packages, but it can cause two "make checksums" to get > locked in a cycle of deleting each other's files and end with one > getting a failed checksum. Yes it happens, I even have used the same disfiles over NFS with more than one machine/poudriere accessing it. The various instances do overwrite each other and checksums do fail but usually in the end one of them "wins" and the correct file ends up being completed, with other instances reading that one. I agree this happens just by chance and not due to good design. As far as I understand Unix Filesystem semantics each download actually creates a new file, with only the last one to start referencing the actual file visible on the filesystem. So the last one starting to download is the one which will "win" creating the correct file on the FS, then checksumming it and going on. The other files have actuay been deleted and are simply removed from disk as soon as the download ends, if at that point the "winning" one has finished the download, they will checksum that file. There is a chance of the loosing download to end before the winning one ends and overwriting it again, but in my experience with at most 3-4 instances over NFS it usually fixes itself in the long run. IMHO best solution is to make sure you already have distfiles on disk for what you are going to build. -- Guido Falsi ___ 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: Poudriere question
On Mon, 9 May 2016 20:15:12 +0200 Guido Falsi wrote: > On 05/09/16 19:52, Fernando Apesteguía wrote: > > Hi all, > > > > Is it safe to use different invocations of poudriere concurrently > > for different jails but using the same ports collection? > > > > Yes it is, or at least should be. > > The ports trees are mounted read only in the jails, the wrkdir is > defined at a different path. What about the distfiles directory? Having two "make checksums" running on the same file used to work fairly well, but not any more because the target now deletes an incomplete file rather than trying to resume it. This wont damage packages, but it can cause two "make checksums" to get locked in a cycle of deleting each other's files and end with one getting a failed checksum. ___ 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 you maintain which are out of date
Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/po...@freebsd.org.html Port| Current version | New version +-+ editors/neovim | 0.1.4 | nightly +-+ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt Thanks. ___ 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"
