FreeBSD Port: deskutils/calibre
Hi! Last port freezed install with: * * Running install * INSTALL paths: LIB: /usr/ports/deskutils/calibre/work/stage/usr/local/lib/calibre SHARE: /usr/ports/deskutils/calibre/work/stage/usr/local/share/calibre Installing binary: /usr/ports/deskutils/calibre/work/stage/usr/local/bin/ebook-device Installing binary: /usr/ports/deskutils/calibre/work/stage/usr/local/bin/ebook-meta Installing binary: /usr/ports/deskutils/calibre/work/stage/usr/local/bin/ebook-convert Installing binary: /usr/ports/deskutils/calibre/work/stage/usr/local/bin/ebook-polish Installing binary: /usr/ports/deskutils/calibre/work/stage/usr/local/bin/markdown-calibre Installing binary: /usr/ports/deskutils/calibre/work/stage/usr/local/bin/web2disk Installing binary: /usr/ports/deskutils/calibre/work/stage/usr/local/bin/calibre-server Installing binary: /usr/ports/deskutils/calibre/work/stage/usr/local/bin/lrf2lrs Installing binary: /usr/ports/deskutils/calibre/work/stage/usr/local/bin/lrs2lrf Installing binary: /usr/ports/deskutils/calibre/work/stage/usr/local/bin/calibre-debug Installing binary: /usr/ports/deskutils/calibre/work/stage/usr/local/bin/calibredb Installing binary: /usr/ports/deskutils/calibre/work/stage/usr/local/bin/calibre-parallel Installing binary: /usr/ports/deskutils/calibre/work/stage/usr/local/bin/calibre-customize Installing binary: /usr/ports/deskutils/calibre/work/stage/usr/local/bin/calibre-complete Installing binary: /usr/ports/deskutils/calibre/work/stage/usr/local/bin/fetch-ebook-metadata Installing binary: /usr/ports/deskutils/calibre/work/stage/usr/local/bin/calibre-smtp Installing binary: /usr/ports/deskutils/calibre/work/stage/usr/local/bin/calibre Installing binary: /usr/ports/deskutils/calibre/work/stage/usr/local/bin/lrfviewer Installing binary: /usr/ports/deskutils/calibre/work/stage/usr/local/bin/ebook-viewer Installing binary: /usr/ports/deskutils/calibre/work/stage/usr/local/bin/ebook-edit Installing code to /usr/ports/deskutils/calibre/work/stage/usr/local/lib/calibre Installing resources to /usr/ports/deskutils/calibre/work/stage/usr/local/share/calibre Setting up command-line completion... Installing bash completion to: /usr/ports/deskutils/calibre/work/stage/usr/local/share/bash-completion/completions/calibre Setting up desktop integration... -- 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: PHP7 package?
Hello, On 2/11/16 11:20 AM, Kurt Jaeger wrote: Hi! That's fewer than I'd have thought, but there are also ports like php56-redis which don't show up as "pecl" though they are in the PECL repo. Then we have to add them manually to the 'ports-to-test' list. I'd say that in order to be rigorous, all php*- and pecl- ports need to be tested (at least) for compilation against php70 in in a clean system, and it's a good opportunity to update all with current versions. I'm happy to help. Feel free to contact me off list. Three tests then: build-test, run-test, use-test I've run some initial tests on PHP 7.0 and 10-STABLE in jails. The good news is I have definitely seen quantifiable page load time improvements in a small (~150 blogs of varying activity) WordPress Multisite installation using nginx and php-fpm that I tested using both Pingdom's page load test and curl's "time_starttransfer" result from nearby and remote IP's. This is evident even with the use of a Redis object cache via predis. The bad news is there seems to be a bug in php-fpm. When started at jail startup it results in the following: last pid: 61693; load averages: 4.69, 2.11, 1.07 up 13+14:07:02 20:50:42 16 processes: 6 running, 10 sleeping CPU 0: 37.8% user, 0.0% nice, 61.4% system, 0.8% interrupt, 0.0% idle CPU 1: 41.7% user, 0.0% nice, 58.3% system, 0.0% interrupt, 0.0% idle CPU 2: 29.9% user, 0.0% nice, 70.1% system, 0.0% interrupt, 0.0% idle CPU 3: 42.5% user, 0.0% nice, 57.5% system, 0.0% interrupt, 0.0% idle Mem: 327M Active, 1531M Inact, 13G Wired, 27M Cache, 236M Buf, 963M Free ARC: 10G Total, 4367M MFU, 3956M MRU, 691K Anon, 131M Header, 1824M Other Swap: 8192M Total, 8192M Free PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 61600 www 1 960 155M 25160K RUN 2 1:41 84.47% php-fpm: pool www (php-fpm) 61587 www 1 960 155M 25160K CPU11 1:38 81.88% php-fpm: pool www (php-fpm) 61588 www 1 960 155M 25160K CPU33 1:41 77.49% php-fpm: pool www (php-fpm) 61536 www 1 960 155M 25160K CPU22 1:44 77.29% php-fpm: pool www (php-fpm) 61535 www 1 960 155M 25160K RUN 0 1:40 76.76% php-fpm: pool www (php-fpm) This is fixed by restarting php-fpm. Otherwise these processes will spin out of control happily consuming 60-90% of each CPU indefinitely. For now my somewhat less than elegant workaround has been to restart php-fpm using a cron and a five second sleep after boot. It never recurs, at least not after 24 hours. I haven't had a chance to look into this further but am curious if anyone else has noticed it. Note that these children are spawned inappropriately as there are no requests coming into this particular jail and pm.start_servers is set to the default of 2 with the default pm.max_children = 5. After restart there are just the 2 children behaving as expected. -- Jim Ohlstein "Never argue with a fool, onlookers may not be able to tell the difference." - Mark Twain ___ 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"
ports/pkg/OS integration 2.0
Royce wrote: > It would be nice to be asked at the point of installing the system > what kind of software management you want: > > [X] Install software from binary packages only > [ ] Install software from ports only (compiling everything locally) > [ ] Prefer packages, prompting me when default options change > [ ] Prefer ports, but use packages if the port options are identical I can't tell if you realize that Synth already does this. well, not the first one because if a person used binary packages *only* then Synth has nothing to do. But there is definitely an option to use official FreeBSD packages instead of building when they are "suitable" which includes identical build options. So anyway, this wish is already here. John ___ 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: ports/pkg/OS integration 2.0 (was: Re: Removing documentation)
On Fri, Feb 12, 2016 at 1:07 PM, Roger Marquis wrote: >>> (The Ubuntu /etc/alternatives symlink system and other mechanisms solve >>> this well) > > > That hasn't been my experience but then I'm not a big fan of symlinks > which can't be safely modified outside of the (d)pkg system. As a > general rule you want to avoid such unnecessary layers of abstraction > where possible. > >>> * if the user's port configuration options aren't different from the >>> package defaults, ask the user if they want to use the package instead >>> (with global and per-port knobs to stop asking if the user desires). > > > Can't really see much use for this. Those of us building from source > know when we can install a binary and nobody really wants to be > held-up by another prompt. That's exactly why I suggested the knobs. I regularly run into circumstances where I want to tweak a config option for one port, but I'd actually prefer that its dependencies be packages ... until I need to tweak something else. So in my pie-in-the-sky world, when an upgrade triggers the need to upgrade a dependency, if the config options haven't changed, then install the package automatically; otherwise, show me the new config options (highlighted!), and ask me if I want to change the defaults. If I do, that dependency becomes managed from ports. If I don't, it stays managed by packages. The knobs would let you make this behavior possible -- or not. It would be nice to be asked at the point of installing the system what kind of software management you want: [X] Install software from binary packages only [ ] Install software from ports only (compiling everything locally) [ ] Prefer packages, prompting me when default options change [ ] Prefer ports, but use packages if the port options are identical Royce ___ 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: ports/pkg/OS integration 2.0 (was: Re: Removing documentation)
(The Ubuntu /etc/alternatives symlink system and other mechanisms solve this well) That hasn't been my experience but then I'm not a big fan of symlinks which can't be safely modified outside of the (d)pkg system. As a general rule you want to avoid such unnecessary layers of abstraction where possible. * if the user's port configuration options aren't different from the package defaults, ask the user if they want to use the package instead (with global and per-port knobs to stop asking if the user desires). Can't really see much use for this. Those of us building from source know when we can install a binary and nobody really wants to be held-up by another prompt. Roger ___ 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: Unexpected dependencies of graphics/libGL
On 19/01/2016 07:59, Manfred Antar wrote: > As an added note the new dependencies also break the build on > Sparc64 clang will not build on Sparc64 although llvm will. So i’m > stuck with the earlier version of dri libGl etc. If there was a way > to turn off the depend on clang llvm it would be nice. Hi! Hmm, that's a problem indeed. I filed a bug report: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207135 Thanks! -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: Fw: Unexpected dependencies of graphics/libGL
On 19/01/2016 05:49, Luís Fernando Schultz Xavier da Silveira wrote: > Since the beginning of this year, graphics/libGL and friends started > depending on a significant amount of software, including git and bzr. > Could anyone explain why that is and whether it is possible to avoid > such dependencies? Hello! I'm not sure how you end up with git and bzr. Maybe git is required by a depency downloaded from GitHub. As for bzr, I have no idea: I don't have it installed and I frequently build Mesa ports. > Also, there is a dependency on clang and llvm from ports because of > advanced features that I (and I guess many of us) do not require. > I believe it has to do with the Gallium driver and OpenCL. Yes, this is correct, LLVM is required to build and run the Radeon Gallium drivers and OpenCL. When the Ports tree will allow to build subpackages from one port, then we will be able to achieve that for runtime dependencies (ie. only install LLVM if you install the Radeon Gallium driver or libOpenCL.so). For the build time, no, we won't add an option to drop LLVM. We already spent a significant amount of time to cleanup Mesa ports so they are all built correctly (they are all built with the same configure flags). Now, it's way easier to maintain those ports, so we won't go back to where we were. As for the version of LLVM, we can't use the one in base because it contains only parts of LLVM. Anyway, the API breaks with every releases of LLVM. Mesa or libclc developers can only support a couple versions of LLVM at one time. -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: Removing documentation
Hi! Michelle wrote: > ports (post pkg) from source: exactly the same problems as pre-pkg plus > occasionally the DB would get corrupted and then you have to nuke the > entire package system from orbit and reinstall all the ports. Interestingly, I had my cases of strange dependencies chains, but I can't remember a case where the pkg-db was really trashed to no longer function. The more recent pkg versions are very robust for my use cases. -- p...@opsec.eu+49 171 3101372 4 years to go ! ___ 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: Removing documentation
William A. Mahaffey III wrote: > > There was a thread a month or 2 back that mentioned adopting the pkg > 'package format' for binary base packages. Yeah that would be the final nail.. ...and then we have an OS that relies on an sqlite db to be patched up correctly... why not go with BerkeleyDB .. oh wait, nevermind... how about going the whole hog and putting in a registry...that'll work, somewhere to store those pesky DWORDs so you could move rc.conf there as well... oh and the registry of installed ports there as well... No further comment necessary. -- Michelle Sullivan http://www.mhix.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: Recent update of security/nettle broke security/keepassx2
Apologies; it was apparently libgcrypt, not nettle. On 02/12/16 09:29, Richard Kuhns wrote: > Hi all, > > After updating security/nettle, when I try to start keepassx2 I get: > > : rjk$~; keepassx > O j: Assertion `ctx->unused < 64' failed > (salsa20.c:400:salsa20_do_encrypt_stream) > Abort trap > -- Richard Kuhns Wintek Corporation 427 N 6th Street Lafayette, IN 47901-2211 Main: 765-742-8428 Direct: 765-269-8541 ___ 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: ports/pkg/OS integration 2.0 (was: Re: Removing documentation)
Hello, On 2/12/16 11:25 AM, Royce Williams wrote: On Fri, Feb 12, 2016 at 6:38 AM, Royce Williams wrote: This is, indeed, a gap in the Debian world. It's one that the ports system is a great start towards resolving. That's why I think that ports + pkg could be a superior offering that people would flock to, and which deserves more focus. To be fair, this is also why my comparison FreeBSD's ports system to some other OSes binary package system is an unfair comparison. :) The complexity of letting people pick their own compilation options is significant, and one that the Linux/Debian/dpkg world largely sidesteps. But it's exactly where I think that FreeBSD could really shine. FreeBSD's ports system is the best system I've seen for managing custom compilation. If the OS, binary packages, and ports were more tightly integrated, it would be magic. Some goals: * The OS needs a structured way to know that a different package has changed its default behavior in some way. (The Ubuntu /etc/alternatives symlink system and other mechanisms solve this well). In other words, a common framework that could accommodate things like deciding to use a port or package instead of the facility provided by the OS. This is true. That probably would not be impossible to implement. It would be nice to be able to have two or more versions of a tool installed and relatively seamlessly switchable, at least for testing. I'm thinking PHP, Apache, nginx, etc. /usr/local/bin/php5 and /usrlocal/bin/php7 with one at any time symlinked to /usr/local/bin/php or /usr/local/alternatives/php or whatever. * Port maintainers should be able to express how one-offs and conflicts should be resolved in a machine-readable way. (In other words, as a test of fitness to purpose, most historic entries in /usr/ports/UPDATING should be programmatically expressible in the system). Yes! * The ports system needs to know which compilation options were used by packages in the pkg system, so that if a conflict arises, it can be intelligently expressed by the maintainers (or the user can be told that they are mutually exclusive). I believe at this time all official packages are compiled with the particular port's default options. That is until "flavors" are implemented at some point in the future. * if the user's port configuration options aren't different from the package defaults, ask the user if they want to use the package instead (with global and per-port knobs to stop asking if the user desires). Another big YES! In other words, the end goal should be that the OS, ports, and packages can coexist for common use cases. -- Jim Ohlstein "Never argue with a fool, onlookers may not be able to tell the difference." - Mark Twain ___ 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: Removing documentation
On 2016/02/12 16:03, William A. Mahaffey III wrote: > There was a thread a month or 2 back that mentioned adopting the pkg > 'package format' for binary base packages. This would at least unify > base & userland binaries under 1 package management system (& I *love* > freebsd-update, BTW, *NO* aspersions being cast here). As I understand > things, there would be separate repo's for base (obviously) & userland, > but 1 unified format/package-manager. For those wanting to compile > either base or userland themselves, they still could, since pkg is > reasonably 'port' aware (& hopefuly could be made /usr/src aware as > well), & they could use whatever src-base/port management tools they > wanted. I definitely agree that a well integrated ability to possibly > mix locally compiled stuff w/ repo-binaries is quite desirable in many > scenarios & a nice advantage for FreeBSD. $0.02 from the (*very*) cheap > seats, no more, no less Yes, this is planned for FreeBSD 11.0-RELEASE. One big chunk of functionality made possible by this change is the ability to selectively install (or not) different bits of the base system -- so you could install FreeBSD /without/ sendmail using the standard binary packages, and maintain it entirely by binary pkg updates. At the moment, if you want a system 'WITHOUT_SENDMAIL' then you have to compile it yourself. Cheers, Matthew signature.asc Description: OpenPGP digital signature
Re: Removing documentation
Royce Williams wrote: > On Fri, Feb 12, 2016 at 5:56 AM, Jim Ohlstein wrote: > > > >> FreeBSD is different in that regard. The ports system is one of the things >> that makes it great. Being able to choose whether to compile everything, >> compile some ports and use official packages (or non-official repos) for >> others, or entirely to use pre-built binaries is one of the great strengths >> of FreeBSD and is one of the features that distinguishes it from most >> flavors of GNU/Linux. There are even tools for creating repos fairly easily. >> Have you ever tried to write a spec file for an RPM based distro? Ugh! >> Unfortunately, dpkg is not designed for people in those first two categories >> above. It can be made to work, but requires much more effort. Add in systemd >> and the nightmare continues... >> > > Interestingly, my experience -- after having been an admin for 70+ > FreeBSD boxes for a 50K+ ISP user base for 12 years -- is different. > > It is the apt-get system that has never failed me, and it is FreeBSD > that has regularly left me with a software installation so wrecked > that I had to deinstall every third party package and start over, or > spending hours scripting a search-and-destroy mission to clean up the > mess. When people with significant FreeBSD experience regularly > recommend the "nuke it from orbit" remedy regularly to people in the > forums, that's a sign that something is deeply wrong. > And from my experience of building and running SORBS over the last 13-14 years on Linux and FreeBSD... Linux: rpms (centos) - every system that used them ended up being replaced because of horrible dependency loops. dpkg (debian) - every couple of years something needs to be upgraded and the OS has to be nuked from orbit (9 out of 10 libc patch) tgz (slackware) - everything compiled from source management was a nightmare but *never* resulted in unbootable systems... dependency - well you had to manage that yourself. FreeBSD: source upgrade (OS): only failed at 5.x and that was bad. freebsd-update (OS): several failures - particularly 9.x, particularly around 9.3-p5 and 9.0->9.3 (in one jump) ports (pre-pkg) from source: mostly worked fine - problems with options changing and defaults changing. ports (post pkg) from source: exactly the same problems as pre-pkg plus occasionally the DB would get corrupted and then you have to nuke the entire package system from orbit and reinstall all the ports. ports (pre-pkg) from precompiled: finding the right version for the system was always the issue because it was generally a moving target about what was on the system and what was not. ports (post-pkg) from precompiled: pretty much nuke and reinstall everything everytime to be 100% sure it's all done which pkg makes trivial... except when the DB blows up... which is when you need to have a list of your ports that you need on the system... Note: I don't use pkg at all anymore, don't even bother testing, gave up on that when it nuked a remote system and left me unable to get in... which resulted in an OS reload (from late 8.x IPMI remote consoles don't work so when pkg nukes the sudo install and you have only allowed ssh logins as a user (not root) - which is the FreeBSD default... well rather than spreading FreeBSD in the company (to 1000's of machines) we (others in the company) are now looking at the alternative and replacing the 50+ SORBS ones... Congrats guys!) > My Linux/dpkg/apt-get experience is entirely different. I have pushed > dpkg-based systems through three major OS/ABI upgrades with one or two > commands, almost without having to perform any manual steps at all -- > and when I did, someone had captured them as part of the package > system, informed me about it up front in the release notes, and almost > always empowered me to run a simple package command to do what needed > to be done automatically. To be clear, this is not "hey, the default > version of perl has changed, please do one of these five things, and > if they don't work, delete everything and start over" > /usr/ports/UPDATING equivalent. These were genuinely deep things that > justifiably required a human to decide which way they wanted to go. > And there was no ambiguity in the official documentation about which > commands I needed to run -- because there was a single, official > method included in the base OS. > > Managing software across FreeBSD OS upgrades, by contrast, is replete > with manual software removal and reinstallation steps, hunting down > old library dependencies, etc. Recurring "nuke it from orbit" > debacles, coupled with the necessity of /usr/ports/UPDATING, makes the > ports system an order of magnitude less reliable than stock > Debian/Ubuntu ports. This upgrade/management friction makes me far > less likely to want to try to upgrade a FreeBSD system, which, in > turn, when faced with a new install of some kind, makes me far more > likely to use and recommend Ubuntu server over FreeBSD.
ports/pkg/OS integration 2.0 (was: Re: Removing documentation)
On Fri, Feb 12, 2016 at 6:38 AM, Royce Williams wrote: > This is, indeed, a gap in the Debian world. It's one that the ports > system is a great start towards resolving. That's why I think that > ports + pkg could be a superior offering that people would flock to, > and which deserves more focus. To be fair, this is also why my comparison FreeBSD's ports system to some other OSes binary package system is an unfair comparison. :) The complexity of letting people pick their own compilation options is significant, and one that the Linux/Debian/dpkg world largely sidesteps. But it's exactly where I think that FreeBSD could really shine. FreeBSD's ports system is the best system I've seen for managing custom compilation. If the OS, binary packages, and ports were more tightly integrated, it would be magic. Some goals: * The OS needs a structured way to know that a different package has changed its default behavior in some way. (The Ubuntu /etc/alternatives symlink system and other mechanisms solve this well). In other words, a common framework that could accommodate things like deciding to use a port or package instead of the facility provided by the OS. * Port maintainers should be able to express how one-offs and conflicts should be resolved in a machine-readable way. (In other words, as a test of fitness to purpose, most historic entries in /usr/ports/UPDATING should be programmatically expressible in the system). * The ports system needs to know which compilation options were used by packages in the pkg system, so that if a conflict arises, it can be intelligently expressed by the maintainers (or the user can be told that they are mutually exclusive). * if the user's port configuration options aren't different from the package defaults, ask the user if they want to use the package instead (with global and per-port knobs to stop asking if the user desires). In other words, the end goal should be that the OS, ports, and packages can coexist for common use cases. Royce ___ 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: Removing documentation
On 02/12/16 09:42, Matthew Seaman wrote: On 12/02/2016 14:56, Jim Ohlstein wrote: This is a good point. I still don't understand why pkg(8) is not in the base (though I imagine there's a reason and it takes less than a minute to install). There can't be many users who install a base system and use it without a single additional piece of software. However, for my $0.02, that is the only change I'd make to base at this point with respect to package management, aside from my pkg(8) wishlist. As an aside, and fwiw, unless there is a non-GPL'd Ada compiler out there, we won't see Ada or any Ada-based binaries in base, even if Synth turns out to be the best thing since sliced bread. The primary reason pkg(8) is not in base is to decouple it from the FreeBSD release timescale. Given the promises about API/ABI stability over a major release branch, development of pkg(8) would be forced to slow to a crawl. pkg(8) still has a lot of changes yet to be realized, both in its own code, and in the code of both the ports and the base system, and in adjunct software like poudriere or indeed, synth, so it is likely to remain a 'port' for some time to come. It is not completely inconceivable though that at some future point, pkg(8) will have matured into stability and require little further development, in which case, importing it to base would be a natural next move. Cheers, Matthew There was a thread a month or 2 back that mentioned adopting the pkg 'package format' for binary base packages. This would at least unify base & userland binaries under 1 package management system (& I *love* freebsd-update, BTW, *NO* aspersions being cast here). As I understand things, there would be separate repo's for base (obviously) & userland, but 1 unified format/package-manager. For those wanting to compile either base or userland themselves, they still could, since pkg is reasonably 'port' aware (& hopefuly could be made /usr/src aware as well), & they could use whatever src-base/port management tools they wanted. I definitely agree that a well integrated ability to possibly mix locally compiled stuff w/ repo-binaries is quite desirable in many scenarios & a nice advantage for FreeBSD. $0.02 from the (*very*) cheap seats, no more, no less -- William A. Mahaffey III -- "The M1 Garand is without doubt the finest implement of war ever devised by man." -- Gen. George S. Patton Jr. ___ 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: Removing documentation
On Fri, Feb 12, 2016 at 5:56 AM, Jim Ohlstein wrote: > On 2/11/16 7:22 PM, Royce Williams wrote: >> Is the abstraction is happening at the equivalent level here? The >> platforms that I'm thinking of -- that appear to have already solved >> this entire class of problem long ago -- feature wrappers around >> apt-get, not wrappers around dpkg. >> >> I'm advocating that we stop quasi-providing four different flavors of >> apt-get. Until there is a single and official mechanism for both >> dependency resolution and configuration option management, the >> fragmentation remains. > > Sadly, I also use dpkg-based systems, not my first choice, but because > sometimes they're the best currently available tool for the job at hand. I'd > need about thirty hands to use my fingers to count how many times apt-get > has left me with a broken package system, though aptitude usually is able to > fix that. Most often that has happened after adding a third party repo (it > happened recently with using MariDB's own repo instead of the official > package) or when compiling from source and trying to delete unnecessary > cruft. The biggest drawback to those systems is that compiling software and > registering it can be a pain in the ass. The second biggest problem is those > systems (Debian and Ubuntu specifically) are built around users who are > totally willing to have the developers choose which options will be compiled > in to "official" and "non-official" repos. That is, people who compile their > own binaries are really an afterthought in the Debian and Ubuntu world. Some > might call that a strength, and yes, dpkg is a nice system for people who > want that kind of thing. It's made Debian based systems very popular, no > doubt about it. Third-party repos are an entirely other kettle of fish, I think. At that point, you're throwing yourself on the mercy of uncoordinated third-party dependency information that conflicts with the official one, and the dpkg/apt-get system should not be held responsible for that. > FreeBSD is different in that regard. The ports system is one of the things > that makes it great. Being able to choose whether to compile everything, > compile some ports and use official packages (or non-official repos) for > others, or entirely to use pre-built binaries is one of the great strengths > of FreeBSD and is one of the features that distinguishes it from most > flavors of GNU/Linux. There are even tools for creating repos fairly easily. > Have you ever tried to write a spec file for an RPM based distro? Ugh! > Unfortunately, dpkg is not designed for people in those first two categories > above. It can be made to work, but requires much more effort. Add in systemd > and the nightmare continues... Interestingly, my experience -- after having been an admin for 70+ FreeBSD boxes for a 50K+ ISP user base for 12 years -- is different. It is the apt-get system that has never failed me, and it is FreeBSD that has regularly left me with a software installation so wrecked that I had to deinstall every third party package and start over, or spending hours scripting a search-and-destroy mission to clean up the mess. When people with significant FreeBSD experience regularly recommend the "nuke it from orbit" remedy regularly to people in the forums, that's a sign that something is deeply wrong. My Linux/dpkg/apt-get experience is entirely different. I have pushed dpkg-based systems through three major OS/ABI upgrades with one or two commands, almost without having to perform any manual steps at all -- and when I did, someone had captured them as part of the package system, informed me about it up front in the release notes, and almost always empowered me to run a simple package command to do what needed to be done automatically. To be clear, this is not "hey, the default version of perl has changed, please do one of these five things, and if they don't work, delete everything and start over" /usr/ports/UPDATING equivalent. These were genuinely deep things that justifiably required a human to decide which way they wanted to go. And there was no ambiguity in the official documentation about which commands I needed to run -- because there was a single, official method included in the base OS. Managing software across FreeBSD OS upgrades, by contrast, is replete with manual software removal and reinstallation steps, hunting down old library dependencies, etc. Recurring "nuke it from orbit" debacles, coupled with the necessity of /usr/ports/UPDATING, makes the ports system an order of magnitude less reliable than stock Debian/Ubuntu ports. This upgrade/management friction makes me far less likely to want to try to upgrade a FreeBSD system, which, in turn, when faced with a new install of some kind, makes me far more likely to use and recommend Ubuntu server over FreeBSD. This pains me greatly, as I have been a FreeBSD advocate/fan for fifteen years, and I believe that FreeBSD's tightly integrated kernel/
Re: Removing documentation
On 12/02/2016 14:56, Jim Ohlstein wrote: > This is a good point. I still don't understand why pkg(8) is not in the > base (though I imagine there's a reason and it takes less than a minute > to install). There can't be many users who install a base system and use > it without a single additional piece of software. However, for my $0.02, > that is the only change I'd make to base at this point with respect to > package management, aside from my pkg(8) wishlist. As an aside, and > fwiw, unless there is a non-GPL'd Ada compiler out there, we won't see > Ada or any Ada-based binaries in base, even if Synth turns out to be the > best thing since sliced bread. The primary reason pkg(8) is not in base is to decouple it from the FreeBSD release timescale. Given the promises about API/ABI stability over a major release branch, development of pkg(8) would be forced to slow to a crawl. pkg(8) still has a lot of changes yet to be realized, both in its own code, and in the code of both the ports and the base system, and in adjunct software like poudriere or indeed, synth, so it is likely to remain a 'port' for some time to come. It is not completely inconceivable though that at some future point, pkg(8) will have matured into stability and require little further development, in which case, importing it to base would be a natural next move. Cheers, Matthew signature.asc Description: OpenPGP digital signature
Re: Removing documentation
Hello, On 2/11/16 7:22 PM, Royce Williams wrote: On Thu, Feb 11, 2016 at 11:17 AM, John Marino wrote: On 2/11/2016 9:08 PM, Royce Williams wrote: On Thu, Feb 11, 2016 at 10:33 AM, John Marino wrote: On 2/11/2016 8:25 PM, Lev Serebryakov wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 07.02.2016 17:28, John Marino wrote: ports-mgmt/synth. I would love to hear what signficant thing portmaster can do that Synth can't. (honestly) Be installed FROM PORTS without all this build-one-more-gcc stuff. Ada? For *port*management* tool? Are you joking? Let me guess. You've spent actually 0.0 nanoseconds preparing on the subject before providing this enlightened take for the list. Having read the entire thread, separate from the relative merits of Synth, the core of Lev's incredulity isn't that off the mark. On the face of it, Synth requiring ncurses seems reasonable ... but its Ada dependency is a bit of a mild POLA violation. Don't get me wrong -- I actually think Ada is pretty cool, and Lev could have been nicer about it ;), but he's essentially right. People's instincts are that software management is core functionality, and should have few unusual dependencies. My earlier side-thread point stands. FreeBSD software management is fragmented. Until that is resolved, a lot of time and effort will be wasted treating the symptoms. Actually, you missed the fact that synth (nor poudriere) doesnt re-invent anything. Both are tightly integrated with pkg(8). You spoke of both as if they were similar to portupgrade. The "wrapper situation" that you proposed is already here. So the whole "fragmented" thing is not really true. Is the abstraction is happening at the equivalent level here? The platforms that I'm thinking of -- that appear to have already solved this entire class of problem long ago -- feature wrappers around apt-get, not wrappers around dpkg. I'm advocating that we stop quasi-providing four different flavors of apt-get. Until there is a single and official mechanism for both dependency resolution and configuration option management, the fragmentation remains. Sadly, I also use dpkg-based systems, not my first choice, but because sometimes they're the best currently available tool for the job at hand. I'd need about thirty hands to use my fingers to count how many times apt-get has left me with a broken package system, though aptitude usually is able to fix that. Most often that has happened after adding a third party repo (it happened recently with using MariDB's own repo instead of the official package) or when compiling from source and trying to delete unnecessary cruft. The biggest drawback to those systems is that compiling software and registering it can be a pain in the ass. The second biggest problem is those systems (Debian and Ubuntu specifically) are built around users who are totally willing to have the developers choose which options will be compiled in to "official" and "non-official" repos. That is, people who compile their own binaries are really an afterthought in the Debian and Ubuntu world. Some might call that a strength, and yes, dpkg is a nice system for people who want that kind of thing. It's made Debian based systems very popular, no doubt about it. FreeBSD is different in that regard. The ports system is one of the things that makes it great. Being able to choose whether to compile everything, compile some ports and use official packages (or non-official repos) for others, or entirely to use pre-built binaries is one of the great strengths of FreeBSD and is one of the features that distinguishes it from most flavors of GNU/Linux. There are even tools for creating repos fairly easily. Have you ever tried to write a spec file for an RPM based distro? Ugh! Unfortunately, dpkg is not designed for people in those first two categories above. It can be made to work, but requires much more effort. Add in systemd and the nightmare continues... This discussion is aimed at people who prefer to compile at least some of their own binaries, else they wouldn't need Portmaster or Synth or poudriere or portupgrade. Really and truly, and with due respect, speaking about dpkg is really a diversion, unintentional as it may be, and detracts from your main point about a totally unified package/ports system, which you believe belongs in base. I don't entirely disagree with that, but having choices about what wraps around pkg(8) should be up to the user. I use poudriere. For my purposes it's the best available tool. Even if you have half a dozen jails on one box poudriere + pkg makes distributing binaries to those jails a joy. Synth might do the same. Portmaster might be satisfactory for building a small number of ports in a system that mostly uses official packages. Portupgrade, if you can live with the ruby dependency and the occasional risk that it will crap out when upgrading a dependency, still works well for solitar
Recent update of security/nettle broke security/keepassx2
Hi all, After updating security/nettle, when I try to start keepassx2 I get: : rjk$~; keepassx O j: Assertion `ctx->unused < 64' failed (salsa20.c:400:salsa20_do_encrypt_stream) Abort trap -- Richard Kuhns Wintek Corporation 427 N 6th Street Lafayette, IN 47901-2211 Main: 765-742-8428 Direct: 765-269-8541 ___ 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: Removing documentation
On 2/12/2016 1:29 PM, Lev Serebryakov wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On 12.02.2016 03:41, John Marino wrote: > >> THERE'S NO REQUIREMENT THAT SOMETHING THAT BUILDS PORTS NEEDS THAT >> ITSELF IS BUILT FROM PORTS. You responded to something different. > If I want to use binary packages, I don't need synth, right? If I > want to use ports, I want to use ports, not binary package for synth + > ports. It is funny and annoying, that tool to manage PORTS better be > installed NOT FROM PORTS (or you need another toolchain not in base > system). > > It is not strict requirement, yes. It is another fallacy. 1) you don't need Synth at all. It's a luxury for people that want things correct on their system. For people that are happy with risks (whether they choose to recognize and/or acknowledge them or not), PM and live-building from source is still available. 2) Anybody with a strict "I don't take packages at all" policy have much bigger concerns than building one more gcc. Their policy will hit them all over the place, so the "joke" here is the objection. You'll build everything you need from the entire tree, but you draw the line at one port? It is illogical to have that policy and then complain about the obvious consequences of that policy. ___ 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: Removing documentation
On 2/12/2016 1:26 PM, Lev Serebryakov wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On 12.02.2016 03:22, Royce Williams wrote: > >> As long as the ports system exists (and I think it should!), the >> management of compilation requirements -- especially for something >> that might need to be bootstrapped early, like a software >> management tool -- is a valid topic. > THIS. What "This"? He was wrong. There's no bootstrapping. It doesn't apply. You are "thumbs up"ing a fallacy. It makes no sense at all. I am sure is sounds great 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: Removing documentation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 12.02.2016 03:41, John Marino wrote: > THERE'S NO REQUIREMENT THAT SOMETHING THAT BUILDS PORTS NEEDS THAT > ITSELF IS BUILT FROM PORTS. You responded to something different. If I want to use binary packages, I don't need synth, right? If I want to use ports, I want to use ports, not binary package for synth + ports. It is funny and annoying, that tool to manage PORTS better be installed NOT FROM PORTS (or you need another toolchain not in base system). It is not strict requirement, yes. - -- // Lev Serebryakov -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQJ8BAEBCgBmBQJWvdA2XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePjm4QAI0XoT+CBh8Sp/XZuxoEgkyJ idXTuCgAC3OakonHLEe7Ng4JbDwcdGQbiOhY1pv4lINNea+wpnjuJXfnf4yGeV+E QZblLvfaDPZBISrvV7AScvHiu8D6atgXNlop+pJQo0uV3yQE+susKUYIrP3vbptO 4Ap6X6wEYNyr3eKHkhgOnT+5kW1vrdphxU74bvq7J6u0LY6U8Oh3DvFITuBNCDIb M7Ug9o4uu+J+BouXnJw70sGJnDzHM9VdrLvki2Zj8R9/WcOukxzkr3v2G7khi2cE 5DINj2daXT7J8XgFwpbBgkfPSRJSM0so0+OdRnTEFXf17mJOyY2VI530cwz928IW 6aH9RQr4eaBNyHpRzMTT5JNXK4LcKA4HDQmr2xP+lI+j1YMEJJ//5B/vb4yTwrFl Zh2ueC2T1oZIAOl8xjpbGfepjaNG7KosCXdvKKjYGp84iNnbq+W5D9dt+0Tng1A6 EhrfzUmDjwz1aYOlDqPlvFTAeNr9z0ISFrElY/IE+2bdk/R/zvRLKy1LTadW0i4n yMeQbezQPXIkEQBDH3S0wFYB3na+W4viA7lcy+3scDxo9NvxdAk7CH4WDvYFsKqU Bgc45QT1nKaThutNU6wc/4eyv2Bb+/qkvpEXCtky+IKPXb1eBMSMmrcZeTfffz2L qweGy/WcL93Nfwp08uHi =4QJQ -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: Removing documentation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 12.02.2016 03:22, Royce Williams wrote: > As long as the ports system exists (and I think it should!), the > management of compilation requirements -- especially for something > that might need to be bootstrapped early, like a software > management tool -- is a valid topic. THIS. - -- // Lev Serebryakov -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQJ8BAEBCgBmBQJWvc9dXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EeP6gIP/iwlLoySKsPTglpVPu9nEvwI hW2OVyVjp2Kk0nvQwARQ76jSgJ/b9ze4m9zQAPPLxgwoaCP05AlLUrGf2XmQmD5r Qxd5VmaLx1qc8IMh7Aa+FszEqcsgNW1j90nL/4YVD9xVydLSiuPSgsIxqagkuk/s FsB3Y0ZHMSEvEv6yheOujHCUmB/poHdZl9sM7bJd1+OlAoWr9ePFu+crnceelgF1 qSdWYingjvaKKABBzkaRpAWAIC/doZ1HifPSbpNROcovWD23KMr466Ldg+I1n8rQ gQVzN4bQJ8jXmvz+8wchOMQQB47igGDY6fjGbZ9rU1VjC8XvhF35qSsYea59bBZ8 WJMuCNeSGQtcgkd7J5WqSZQTzxOLQK+NMruw/tjl0NrjOvyFGSLBn9gUJoUQtOpD NN+AVq11eooTWV3MpbpCkoxvyS0a1a7znUmaHT64YvtSua9xK4lFqWdBrF07te8h UMMuLzSizOvlONDi4WNgBIRbBYGo7uurdFQrAbVkaSCBGgRqTPwaR4CpCq+rtsOj OEr+TY1k33pBa2bsc9z5Rnjs3X8OW+Lc6CURrnqnDpiIGpZuL+qkTYQ2Ig4wp+Ip NIBSL48sugVKHtMRfFmp/ycgUiyWX6N3Mc6zrj4/RosbiJVp2c7AmDi5VCGNlMMc oXvZ+lroIy6Y1opC+Oue =PgK+ -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: Removing documentation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 12.02.2016 00:32, Matt Smith wrote: >>> ports-mgmt/synth. I would love to hear what signficant thing >>> portmaster can do that Synth can't. (honestly) >> Be installed FROM PORTS without all this build-one-more-gcc >> stuff. Ada? For *port*management* tool? Are you joking? > > Remember that before portmaster we had cvsup which was written in > Modula-3 and portupgrade which is written in Ruby. Whilst it is > nice that portmaster is just a simple shell script with no > dependancies that's a relatively new thing. I remember cvsup (great tool, for sure) as only-binary-package-on-my-self-build-system, yes. And it annoyed me a bit every time, that I need to download binary package :) - -- // Lev Serebryakov -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQJ8BAEBCgBmBQJWvc7ZXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePDrUP/33yYFNyrBKwfeSXQwxuqHZ7 l9VlJFzEwSGqM4pXstYZjkrv8MGYTbfpD9KLd2vURClTO3J9QU1FNugRw+8XkLi3 4sekwg3sxfN+vVIYvB/Oy5lcvl3u6sdOt8SRar5OYVkpoqhE0PHYeGpyCUT45BXy RgdZFeQiBjwsxR2cphZtNbeLJPZiZ+fROfFZdfWM5VB5XtPAGrRybYQbCnngMEPb lr84Sdi7yMk1n2LOPUnhpTK1XROn1HcX5EOozhaWmQ3fpV741ji3YvnglwoFbqc2 hOEiPsfrSHFy7Pnykqi0GWyF+QVzSk9xMiuLQjdTBFOjuHlIjJt6oWjBsrDfj+Ki ee2UFN3RgNQhM7gIammfiVJSA1RHlqU9JH8Xn0fihhDgytVZoehmmwXLa3FfMZOJ EAC6kpxG+npJaqJcSsDebyTf+8yTfvBegVEhi+a84EIXQgQr5GqMAPoH/RZgkACE VK+Odc8JvLFGQr5ytOO76N3gl4hcb+07stmrfLmtsoUzNL7mFcgSLQ64TDBTqXML MMBABec/h75XpuWCmCKE2DPSzEhD9D7khoj41no0pRnLf8En9n5FXnqedLCczCmN GwC7av++WeXrMKnBO4wS4vwGNnwO5rdOB6SaL3k1qFCYwEk+z8rWLz+VLPKsDhER uPUiFcyU/BG8hSzV8aqW =9MbF -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: Removing documentation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 11.02.2016 22:33, John Marino wrote: >>> ports-mgmt/synth. I would love to hear what signficant thing >>> portmaster can do that Synth can't. (honestly) >> Be installed FROM PORTS without all this build-one-more-gcc >> stuff. Ada? For *port*management* tool? Are you joking? > > Let me guess. You've spent actually 0.0 nanoseconds preparing on > the subject before providing this enlightened take for the list. Ok, let me expand. I see here contradiction. There are people who prefer binary packages. There are people who prefer ports (local builds). Both ways are perfectly Ok to me. I'm prefer ports, because I have only a few full-featured FreeBSD installations, and I don't like many ports options defaults (=packages defaults). If I have much more FreeBSD hosts, it could be worth for me to have one custom package repository, but in my particular case, it isn't worth it. So, ports. If I'm using ports, I want to use ports. Not "install this from package and that from ports". And in such situation I want to have set of "non-productive" ports (which doesn't solve server's problem, but bookkeeping ones) minimal. This includes all these auto*-crap, gmake, texinfo, and other build-depends. And have here port-to-manage-ports which needs one-more-bloated-gcc-toolachain is not what I want. And I need to have it here, because there will be moment in time when I'll upgrade (rebuild!) synth itself. Synth could be great package for build server. I'll give it a try to build packages for NanoBSD images, for example (instead of poudriere), for sure. But not fore my ports-based installations. - -- // Lev Serebryakov -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQJ8BAEBCgBmBQJWvc44XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePna4P/2GsGsFvhvSQgxyztBiPhnAL TEcgI3tSsHlzezpDXpHbd8R6SpZF+afvTku09gw7NwlQqdyu2HcvNcX6z2Ss6nLD f0GeqM44bvcSN4b43FVfrkqgo3haCcuy05ocC3a76sE3ZgGDiSLnuY7HPn6ndLCa 32+zFcYzsc9MZoZKUoWl6FtnkEANHag/iTU3o1RXk19JErwZ1ZOEzVgc+Spov5GQ vF2Abx7EZV+CI7mwxHRbwt6/Si1kLDBjA9V/GAH6UTXGAiTDSn6z7zgNrvjWy6SY 0UoHho+yUxKYmH4cUU4g+PHIhPJrOQHu39bXd0jzdQq2rSODgYV/Lg5EEjACRaEP DWvnlK/TNDFQGz7+1MU5TeLdtLJ49b7Z7eEGSNrhKDBmkuRakUkDZ/fHBWiztBuK ZquIvsb/L7SdHGCh0ax4SCJJRQ6ynKQ9SWaXBBtqgbWfUvLhp2Jd2vaON3AyfT6j ihxEFmuLD0P3VIEHvoVA3SKuOXLA4boLhPwjvDBQ3Sn5KxeY8TFXjg7EmixphOhC l3g5rekga3vvM9A+Wsg4PpGGWVabwavopu1kT4IBRfXzRHTyIT29C83DjfG6Yyvl UYg53Zv1zOnhK0qjHLKHLCU4UJflIDRLi6tiMQpk5u5WXFZ4on4U1Femq8DeLnan sn3e/ikh6V9XpvhG2OoL =j2XG -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: Removing documentation
On 12.02.2016 07:21, Royce Williams wrote: I'm advocating that we stop quasi-providing four different flavors of apt-get. Until there is a single and official mechanism for both dependency resolution and configuration option management, the fragmentation remains. Why do you think this is the case? Ports defines the dependencies and pkg respects them. I'm not seeing where there more than one method here. What other ones are there? The current ports/pkg relationship is still fragile, perhaps because it's new. I almost abandoned FreeBSD entirely a couple of months ago when an interesting corner case of the use of pkg managed to unilaterally and without warning delete in its entirety the contents of /usr/local/etc/rc.d in of my jails. Contrast this with the Ubuntu world, where there is a well-baked "unattended-upgrades" option that automatically downloads and upgrades all security updates for both the OS and all third-party packages. These are not well-baked, i did find multiple problems with them. Also this is *not* something you really want. If security really is important you do not install software without your explicit approval. There are to many things which can go wrong and normally do. These complains are often in the Ubuntu world. The Ubuntu world is not so bright as you say. ;) Greetings, Torsten ___ 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 +-+ net-mgmt/weathermap | 1.1.1 | 17.0.0 +-+ 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"
Re: Removing documentation
On 12.02.2016 01:41, John Marino wrote: On 2/12/2016 1:22 AM, Royce Williams wrote: Is the abstraction is happening at the equivalent level here? The platforms that I'm thinking of -- that appear to have already solved this entire class of problem long ago -- feature wrappers around apt-get, not wrappers around dpkg. I'm not a linux guy so those things don't mean much the me. The abstraction layer here is at the appropriate level. I'm not seeing this fragmentation problem you're talking about, at least not with the newer tools. I agree in this point with John. Also a clear "no" to the statement, that this problems are solved with apt-get or other tools in the Linux world. This is clearly not true. Did you, Royce, ever try to build something from the source and register it in the packet manager around dpkg? Build your own binary repository and mix it with others? Yes, FreeBSD did miss some features - but for the most use-cases it is much more reliably and flexible than the tools named by you, Royce. Whenever i bring up a comparison between the packet managers there is a clear win for FreeBSD voted by the Linux guys. Most time winning points are something simple like "pkg audit write you an email if there is a security issue". Or having a portstree in an code-repository and therefore the possibility to just go back in time. Or easy change/storable configuration files. If there were no ports system, and everything was package-driven, I'd agree. Synth and its cousins exist because people work from ports -- which means that dependencies matter. Synth exist because people are insisting to build from source (even irrationally) so they might as well do it correctly. The statement above doesn't have anything to do with Synth being a binary. If a shell script was so good, why is portmaster unmaintainable? It is not unmaintainable. But it is not written in a manner which make maintenance very easy. But this is sadly true for most software... Greetings, Torsten ___ 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: Is it a discouraged behavior to limit port's target OS version?
> On 12 Feb 2016, at 09:16, Ardie H. Hwang wrote: > > Hi all, > I need an advice or two regarding the problem I met. > > I am preparing a submission of new port, which depends on : > `databases/mariadb-connector-c`. > Everything went okay, until Poudriere test in 9.3-RELEASE jail reported build > failure. Apparently has been added to base system since > 10.0-RELEASE. > > The question is: this limiting OS version for this port, is this a > discouraged idea? The method I am thinking is to display error if OS version > is less than 10.x, upon checking OSVERSION makevar in Makefile. But this will > discriminate against fellow 9.x users. > I have another solution of adding `converters/iconv` (libiconv.so) as this > port's library dependency. However, I am worried that doing this might cause > problem on 10.x versions. > > Can someone tell me what to do regarding this on 9.x? Please see: https://www.freebsd.org/doc/en/books/porters-handbook/using-iconv.html - 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: Is it a discouraged behavior to limit port's target OS version?
Oh shoot! I should have read the handbook more carefully! Thank you for the answer! On Fri, Feb 12, 2016, at 17:19, Michael Gmelin wrote: > > Please see: > https://www.freebsd.org/doc/en/books/porters-handbook/using-iconv.html > > - michael > -- Ardie H. Hwang email: i...@ardiefox.me mobile: +82 10-I-AM-ARDIE (+82 10-4-26-27343) ___ 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"
Is it a discouraged behavior to limit port's target OS version?
Hi all, I need an advice or two regarding the problem I met. I am preparing a submission of new port, which depends on : `databases/mariadb-connector-c`. Everything went okay, until Poudriere test in 9.3-RELEASE jail reported build failure. Apparently has been added to base system since 10.0-RELEASE. The question is: this limiting OS version for this port, is this a discouraged idea? The method I am thinking is to display error if OS version is less than 10.x, upon checking OSVERSION makevar in Makefile. But this will discriminate against fellow 9.x users. I have another solution of adding `converters/iconv` (libiconv.so) as this port's library dependency. However, I am worried that doing this might cause problem on 10.x versions. Can someone tell me what to do regarding this on 9.x? -- Ardie H. Hwang email: i...@ardiefox.me mobile: +82 10-I-AM-ARDIE (+82 10-4-26-27343) ___ 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"
