FreeBSD Port: zabbix2-frontend-2.0.2_1
Greetings. This port missing php5-simplexml dependency. Without it Import dont work. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
pkgng questions
1. How do I get pkg to use packages built against 9.1-RC1? VirtualBox is playing up (no ethernet, unkillable crashes, etc) and I suspect it's the kernel module... 2. Is there a list of ports like nvidia-driver, nspluginwrapper, linux-f10-flashplugin, sampleicc (dependency of libreoffice!) which aren't in pkgng? 2a. How do I install libreoffice when a dependency isn't in pkgng? 3. How do I force pkg to install/upgrade a single package, regardless of dependencies being out of date? 4. How do I get poudiere to build against a local src/obj tree, or a zfs snapshot of a pre-built jail, instead of 9.0-RELEASE? 5. How do I get poudiere to build against the packages a pkgng client will use instead of building everything for itself? It might help to reduce the discrepancy between the 30 secs it takes to rebuild sysutils/conky from ports on my desktop, and the 1hour it takes poudiere on a hefty server to download+build X and all its dependencies 6. Is pkgng really replacing base when poudiere requires ZFS? How will ports work if pkg_* are gone? Seriously, shouldn't ports at least be able to work with pkgng, and the default FreeBSD install be to a ZFS root before people are stuffed with the wrong choices (UFS) they made? 7. How do I configure pkg to use packages from a certain historical release? I need my servers to be identical software-wise regardless of when I install them. In other words, I DON'T want the latest versions. 8. Is there a pkgng equivalent of 'ls -lt /var/db/pkg' without firing up sqlite? 9. Why didn't pkg upgrade tell me it replaced my custom-built packages? I'd have liked for it to not break stuff when /var/db/ports/*/options differed from the options I can see pkgng keeps in its metadata... -- The information contained in this message is confidential and intended for the addressee only. If you have received this message in error, or there are any problems with its content, please contact the sender. iCritical is a trading name of Critical Software Ltd. Registered in England: 04909220. Registered Office: IC2, Keele Science Park, Keele, Staffordshire, ST5 5NH. This message has been scanned for security threats by iCritical. www.icritical.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: pkgng questions
I think you're very confused about what pkgng is for. At this time, ports are STILL the recommended way to install things and keep them up to date. Pkgng is the first step required for us to get a better package management system so we can shift the community towards primarily using packages. On Thu, 30 Aug 2012 05:05:57 -0500, Matt Burke mattbli...@icritical.com wrote: 1. How do I get pkg to use packages built against 9.1-RC1? VirtualBox is playing up (no ethernet, unkillable crashes, etc) and I suspect it's the kernel module... I'm not sure what you mean here. Do you have a 9.1-RC1 server and you're using a public pkgng repository? Which is probably built against 9.0? 2. Is there a list of ports like nvidia-driver, nspluginwrapper, linux-f10-flashplugin, sampleicc (dependency of libreoffice!) which aren't in pkgng? Everything can be built into the pkgng format except a few ports that need workarounds. There's a list on the wiki. http://wiki.freebsd.org/pkgng Go to the bottom Known Failures section. 2a. How do I install libreoffice when a dependency isn't in pkgng? You run your own poudriere box and setup your own private pkgng repository at this time and build your packages against whatever versions of Perl/Python/PHP/MySQL/etc that you prefer with whichever extra make.conf settings and port options you prefer. My own pkgng repository has libreoffice with no issues. 3. How do I force pkg to install/upgrade a single package, regardless of dependencies being out of date? You should never try to do this anyway; you'll end up with packages built against the wrong versions of libraries. 4. How do I get poudiere to build against a local src/obj tree, or a zfs snapshot of a pre-built jail, instead of 9.0-RELEASE? The poudriere man page has all the instructions needed to create jails of any release version to be used for building packages. 5. How do I get poudiere to build against the packages a pkgng client will use instead of building everything for itself? It might help to reduce the discrepancy between the 30 secs it takes to rebuild sysutils/conky from ports on my desktop, and the 1hour it takes poudiere on a hefty server to download+build X and all its dependencies You don't do it this way. You build everything on your poudriere server and push all of your packages to the client. You do this every single time. If you decide you want a new package on your client, you build it on your poudriere server and have your client request it. If you're using poudriere/pkgng, your clients should NEVER be compiling ports or installing packages outside of what your poudriere server is providing. Poudriere is giving you a cleanroom environment where it can guarantee that all the packages and their required packages/libraries are sane. 6. Is pkgng really replacing base when poudiere requires ZFS? How will ports work if pkg_* are gone? Seriously, shouldn't ports at least be able to work with pkgng, and the default FreeBSD install be to a ZFS root before people are stuffed with the wrong choices (UFS) they made? Pkgng doesn't require ZFS -- poudriere does. Your clients should never have poudriere. 7. How do I configure pkg to use packages from a certain historical release? I need my servers to be identical software-wise regardless of when I install them. In other words, I DON'T want the latest versions. Make sure your poudriere server is using the ports tree snapshot you desire. 8. Is there a pkgng equivalent of 'ls -lt /var/db/pkg' without firing up sqlite? Are you looking for the date column (not sure why that's useful as it can change due to many things)? Doesn't pkg info -a suffice? 9. Why didn't pkg upgrade tell me it replaced my custom-built packages? I'd have liked for it to not break stuff when /var/db/ports/*/options differed from the options I can see pkgng keeps in its metadata... Your poudriere server can use you preferred options when it builds packages. Check the man page. Long story short: poudriere is a tool for you to build your OWN private package repositories (which is really handy!). Pkgng is just the first step towards a large goal of greatly improving the enduser experience with FreeBSD. I don't believe pkgng is default on any release yet, so you shouldn't be using public pkgng repositories for anything but testing. You should either be running your own poudriere server or you should just be using the new pkgng format with ports. I'm sure someone will chime in with more details and possibly corrections if I've missed something. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: pkgng questions
[ Mark Felder wrote on Thu 30.Aug'12 at 7:01:43 -0500 ] I think you're very confused about what pkgng is for. At this time, ports are STILL the recommended way to install things and keep them up to date. Pkgng is the first step required for us to get a better package management system so we can shift the community towards primarily using packages. Can i ask, why is it that shifting the community to using packages is deemed to be a better approach? I like being able to select configuration options to build software. I have never installed a pre-compiled package since using FreeBSD version 6.x. I recall someone responding in another thread about how people don't like change but surely being able to choose is what end-users want. I am sure this has been discussed at length in other threads and sorry if i'm asking old questions. Jamie ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
pkg (aka pkgng) 1.0 released
Hi all, Since Julien Laffaye and I started pkgng lots of things has happened and here we are now. After 2 years of development (first commit Tue Sep 7 2010), more than 2000 commits, 43 different contibutors. The pkgng team is proud to release pkg-1.0! Before going further I would like to thanks any one that has been involved in pkgng providing code: Alberto Villa, Andrej Zverev, Andrey Zonov, Arthur Gautier, Ashish SHUKLA, Beat Gaetzi, Brad Davis, Bryan Drewery, Chris Rees, Craig Rodrigues, Daniel Shahaf, David Forsythe, David Naylor, Eitan Adler, Florent Thoumie, Frederic Culot, Garrett Cooper, Glen Barber, Jonathan Anderson, Koop Mast, Lars Engels, Joffrey Lassignardie, Marco Steinbach, Marin Atanasov Nikolov, Matthew Seaman, Maxim Ignatenko, Michael Brune, Philippe Pepiot, Pietro Cerutti, Rolf Grossmann, Roman Naumann, Sofian Brabez, Sunpoet Po-Chuan Hsieh, Toni Ylenius, Will Andrews, Yuri Pankov There are also some people I would like to thanks in particular: - Will Andrews, who has been the first to join the project after the first presentation at BSDCan 2010. - Jilles Tjoelker, who has been continuously reviewing commit, spotted mistake, provided advices. - Matthew Seaman and Bryan Drewery who have become two of the most active developers in a very short time and have improved pkgng a lot! - Marin Atanasov Nikolov, who has been working heavily on multirepository support, providing continuous integration environement, and many more. - All the portmgr from prior my election as member of that team, they invited us to BSDCan to present our early version of pkgng (which was a really early version :D), they trusted in pkgng and motivated us a lot! Thanks to all the testers/reviewers, early adopters. So, 1/ Why pkg? Our current pkg_install tools are showing their age, are hard to maintain, and they lack features: - missing metadata - no upgrade support - no repository support - no fine dependency tracking - no modern binary package management - and many others Having old tools makes it hard to improve the ports infrastructure, as a result lots of hacks have found their way into the different Mk/bsd.*.mk files to work around pkg_install limitations plus there are lots of hacks in the packages metadata itself such as @comment which are not comments, and so forth. 2/ What it is? -- It is a tool that is designed to replace pkg_install and provide modern features and advanced package management for FreeBSD. The ports tree is already able to transparently switch to pkgng by default by adding WITH_PKGNG=yes to your make.conf It provides a pkg2ng tool to help converting from an old installation to a new one. Test repositories are available on http://pkgbeta.freebsd.org/ (I try to update them as fast as I can) It will live forever in the ports tree (with a binary bootstrap in 9 and 10) Third party tools - Tools supporting natively pkgng - ports-mgmt/portupgrade-devel (soon the main portupgrade will support) - ports-mgmt/pkg_cutleaves - ports-mgmt/poudriere - ports-mgmt/poudriere-devel - ports-mgmt/portdowngrade - ports-mgmt/tinderbox-devel (support can be improved) - ports-mgmt/portbuilder - sysutils/bsdstats Tools supporting pkgng via a patch (I hope it will be reviewed/integrated soon) - ports-mgmt/portmaster (https://github.com/pkgng/pkgng/blob/master/ports/patch-portmaster-pkgng) Tools being worked on (or I heard people are interested) : - salt support (in version 0.10) http://docs.saltstack.org/en/latest/ref/states/all/salt.states.pkgng.html and http://docs.saltstack.org/en/latest/ref/modules/all/salt.modules.pkgng.html - cfengine support (http://unix-heaven.org/cfengine3-freebsd-pkgng) - puppet support: (https://github.com/xaque208/puppet-pkgng) - ruby bindings: (https://github.com/baloo/libpkg-ruby/) - PackageKit Howto: - Continuous integration and package building: http://unix-heaven.org/continuous-package-building-with-poudriere-and-jenkins - Maintaining your own pkgng repository with tinderbox: http://www.glenbarber.us/2012/06/11/Maintaining-Your-Own-pkgng-Repository.html Links - - http://wiki.freebsd.org/PkgPrimer - http://wiki.freebsd.org/pkgng - https://github.com/pkgng/pkgng/blob/master/FAQ.md Please report bugs in the github issue tracker: - http://github.com/pkgng/pkgng Please note the http://pkgbeta.freebsd.org is updated on best effort, there is still a lot of work needed, to be able to automatically and update on regular basis the package sets. regards, Bapt pgpZNAPH67X3q.pgp Description: PGP signature
Re: pkgng questions
On 08/30/12 13:01, Mark Felder wrote: I think you're very confused about what pkgng is for. At this time, ports are STILL the recommended way to install things and keep them up to date. Really? I think the last time I compiled X or a web browser (until using poudriere) was about 10 years ago. Pkgng is the first step required for us to get a better package management system so we can shift the community towards primarily using packages. I like packages - they save me compiling massive things on my desktop and they let me keep my servers running exactly the same software built from our CI setup. 'make package' is so quick and easy, it'd be hard to beat. So I thought I'd get a grip on pkgng before pkg_* disappears from base. I had a couple of questions I wanted to answer - 1) How easy does it make keeping my desktop (currently releng/9.1 built with dtrace) up-to-date 2) How much easier will it be to maintain production and testing servers? The answer has made me start downloading an OpenIndiana iso. 2. Is there a list of ports like nvidia-driver, nspluginwrapper, linux-f10-flashplugin, sampleicc (dependency of libreoffice!) which aren't in pkgng? Everything can be built into the pkgng format except a few ports that need workarounds. There's a list on the wiki. http://wiki.freebsd.org/pkgng Go to the bottom Known Failures section. I don't see any of the examples I gave listed, apart from nvidia-driver 3. How do I force pkg to install/upgrade a single package, regardless of dependencies being out of date? You should never try to do this anyway; you'll end up with packages built against the wrong versions of libraries. You're suggesting that I should upgrade an entire machine which may have proven itself over a period of years to be perfectly stable, just because I need a small utility which really doesn't care about the man page typo which caused gettext-0.1.2_3 to change to gettext-0.1.2_4? 4. How do I get poudiere to build against a local src/obj tree, or a zfs snapshot of a pre-built jail, instead of 9.0-RELEASE? The poudriere man page has all the instructions needed to create jails of any release version to be used for building packages. No, the man page doesn't mention anything about specifying where to pull the distribution from, only what method of access to use. You don't do it this way. You build everything on your poudriere server and push all of your packages to the client. You do this every single time. If you decide you want a new package on your client, you build it on your poudriere server and have your client request it. If you're using poudriere/pkgng, your clients should NEVER be compiling ports or installing packages outside of what your poudriere server is providing. Poudriere is giving you a cleanroom environment where it can guarantee that all the packages and their required packages/libraries are sane. Pkgng doesn't require ZFS -- poudriere does. Your clients should never have poudriere. I am confused. If pkg_* are removed, how is a person with a single desktop machine (worst case, a netbook) expected to operate if they need a specific port build? Are they to spend a week compiling 1000+ ports themselves in a poudriere VM? Or is the flexibility of FreeBSD ports just not deemed to be useful to the end user (or person unable to provide a dedicated any more? 8. Is there a pkgng equivalent of 'ls -lt /var/db/pkg' without firing up sqlite? Are you looking for the date column (not sure why that's useful as it can change due to many things)? Doesn't pkg info -a suffice? 'ls -lt /var/db/pkg' will show me what packages were installed sorted by day. It is very useful on servers which aren't routinely upgraded to the latest and greatest untested versions 9. Why didn't pkg upgrade tell me it replaced my custom-built packages? I'd have liked for it to not break stuff when /var/db/ports/*/options differed from the options I can see pkgng keeps in its metadata... Your poudriere server can use you preferred options when it builds packages. Check the man page. pkg2ng doesn't tell you that you're about to need another machine $ man pkg2ng No manual entry for pkg2ng Long story short: poudriere is a tool for you to build your OWN private package repositories (which is really handy!). It is handy IF you have the resources to maintain a poudriere machine. It is handy IF you really enjoy waiting for x.org and web browsers to compile It is NOT handy if you just want to build one package to be built with different options. In fact it makes a mockery of FreeBSD's ease of use. Pkgng is just the first step towards a large goal of greatly improving the enduser experience with FreeBSD. By improving, you mean removing flexibility from? I don't believe pkgng is default on any release yet, so you shouldn't be using public pkgng repositories for anything but testing. You should either be running your own poudriere server
Re: pkgng questions
On Thu, 30 Aug 2012 08:43:54 -0500, Jamie Paul Griffin ja...@kode5.net wrote: Can i ask, why is it that shifting the community to using packages is deemed to be a better approach? I like being able to select configuration options to build software. I have never installed a pre-compiled package since using FreeBSD version 6.x. The long-term goal is subpackages so this need is alleviated. The only reason to compile yourself then is to play with the CFLAGS. :-) Example: right now if you want to build a webserver running Apache and PHP quickly with FreeBSD you have no choice but to use ports. The PHP package doesn't provide the Apache PHP module. But if we had packages for the independent options: php5-apache, php5-php-fpm, php5-cli, php5-cgi You see where this is going. It's moving toward the modularization that many Linux distros use. Some people are going to hate this, but it makes support for the ports team MUCH more consistent because everyone runs the same binaries. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: pkgng questions
On 8/30/2012 8:43 AM, Jamie Paul Griffin wrote: [ Mark Felder wrote on Thu 30.Aug'12 at 7:01:43 -0500 ] I think you're very confused about what pkgng is for. At this time, ports are STILL the recommended way to install things and keep them up to date. Pkgng is the first step required for us to get a better package management system so we can shift the community towards primarily using packages. Can i ask, why is it that shifting the community to using packages is deemed to be a better approach? I like being able to select configuration options to build software. I have never installed a pre-compiled package since using FreeBSD version 6.x. I recall someone responding in another thread about how people don't like change but surely being able to choose is what end-users want. I am sure this has been discussed at length in other threads and sorry if i'm asking old questions. Jamie Supporting binary package upgrades makes it easier all around for most users. It also simplifies enterprise environments. Users can of course build their own packages with custom options and distribute those instead. Make no mistake though, ports are not going anywhere. You don't have to use binary packages if you don't want to. You can still checkout ports and compile and use portmaster/portupgrade. Bryan ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: pkgng questions
[ Bryan Drewery wrote on Thu 30.Aug'12 at 9:51:55 -0500 ] On 8/30/2012 8:43 AM, Jamie Paul Griffin wrote: [ Mark Felder wrote on Thu 30.Aug'12 at 7:01:43 -0500 ] I think you're very confused about what pkgng is for. At this time, ports are STILL the recommended way to install things and keep them up to date. Pkgng is the first step required for us to get a better package management system so we can shift the community towards primarily using packages. Can i ask, why is it that shifting the community to using packages is deemed to be a better approach? I like being able to select configuration options to build software. I have never installed a pre-compiled package since using FreeBSD version 6.x. I recall someone responding in another thread about how people don't like change but surely being able to choose is what end-users want. I am sure this has been discussed at length in other threads and sorry if i'm asking old questions. Jamie Supporting binary package upgrades makes it easier all around for most users. It also simplifies enterprise environments. Users can of course build their own packages with custom options and distribute those instead. Make no mistake though, ports are not going anywhere. You don't have to use binary packages if you don't want to. You can still checkout ports and compile and use portmaster/portupgrade. Thanks Bryan for explaining. And sorry for creating a digression from the OP's question. I'm just reading all the information about pkgng, poudriere and related projects and it looks pretty fantastic. Some really creative and clever work. Best wishes, Jamie. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: pkg (aka pkgng) 1.0 released
Thanks to everyone involved. I've been lightly testing pkg for a little while, but I still mainly use ports. This announcement prompted me to switch from portupgrade to portupgrade-devel (20120827 version) to see how it works with PKGNG. I encountered a couple issues: Portupgrade doesn't remove the pkgdb.db.lock reliably. Portupgrade doesn't handle stale lock files (just waits indefinitely for a nonexistent process to finish). A big problem when combined with the above. Running portupgrade pkg failed. It stalled trying to unregister the package installation after the old pkg was removed. I didn't dig too deeply but it seems like a dependency chicken-and-egg problem. I was able to reinstall using /usr/sbin/pkg, and I also tested make make deinstall make reinstall of ports-mgmt/pkg successfully, so it may just be a portupgrade issue. JN On Aug 30, 2012, at 8:19 AM, Baptiste Daroussin b...@freebsd.org wrote: After 2 years of development (first commit Tue Sep 7 2010), more than 2000 commits, 43 different contibutors. The pkgng team is proud to release pkg-1.0! [...] Tools supporting natively pkgng - ports-mgmt/portupgrade-devel (soon the main portupgrade will support) [...] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: pkgng questions
On Thu, 30 Aug 2012 09:44:42 -0500, Matt Burke mattbli...@icritical.com wrote: On 08/30/12 13:01, Mark Felder wrote: I think you're very confused about what pkgng is for. At this time, ports are STILL the recommended way to install things and keep them up to date. Really? I think the last time I compiled X or a web browser (until using poudriere) was about 10 years ago. Yes, but an example I gave in another thread reply is PHP. You can't pkg_install PHP right now and get Apache support. You HAVE to compile. The new pkg format is a step towards sub-packages so we can have a better public package repository that can fill 99% of everyone's needs. I had a couple of questions I wanted to answer - 1) How easy does it make keeping my desktop (currently releng/9.1 built with dtrace) up-to-date It should be no different -- perhaps easier even. 2) How much easier will it be to maintain production and testing servers? It will be no different. In fact, if you have a lot of servers but you have consistent, customized options across them all it will be EASIER to deploy and update packages with pkgng and poudriere. The answer has made me start downloading an OpenIndiana iso. I don't see what OpenIndiana gains you...? I don't see any of the examples I gave listed, apart from nvidia-driver Because the examples you gave have no issues with pkgng. If they're not in the public repository that's not a pkgng problem, it's a repository problem. You should be using pkg_* until the ports@ team has stated that the public pkgng repository is the one everyone should be using. pkgng 1.0 has just been announced, but that just means the tool has reached maturity, not the package management of FreeBSD has instantly changed to pkgng. You're suggesting that I should upgrade an entire machine which may have proven itself over a period of years to be perfectly stable, just because I need a small utility which really doesn't care about the man page typo which caused gettext-0.1.2_3 to change to gettext-0.1.2_4? I'm not sure how you've come to this conclusion? If you have a poudriere server building packages and you only want to install one new utility, just tell poudriere to build only that utility and not build your entire list of packages. Yes, if that utility depends on gettext you'll find poudriere upgrading gettext and everything that depends on it. That's what poudriere does -- make sure that everything is built against whatever is current in the ports tree provided. But again, we're getting into the realm of mixing ports and packages which you should always take great caution when doing. You'll still be able to do that with pkgng. 4. How do I get poudiere to build against a local src/obj tree, or a zfs snapshot of a pre-built jail, instead of 9.0-RELEASE? The poudriere man page has all the instructions needed to create jails of any release version to be used for building packages. No, the man page doesn't mention anything about specifying where to pull the distribution from, only what method of access to use. poudriere jail -c -v 8.3-RELEASE -a amd64 -j 8stable-amd64 This builds a jail from 8.3-RELEASE. If you want to update it to 8-STABLE build the 8-STABLE world and make installworld DESTDIR=/path/to/poudriere/jail/named/8stable-amd64 Does that help? I am confused. If pkg_* are removed, how is a person with a single desktop machine (worst case, a netbook) expected to operate if they need a specific port build? Are they to spend a week compiling 1000+ ports themselves in a poudriere VM? Or is the flexibility of FreeBSD ports just not deemed to be useful to the end user (or person unable to provide a dedicated any more? Do not change what you are currently doing. Keep using pkg_* until the pkgng repositories are deemed to be the official package repositories of FreeBSD. If you really know what you're doing, you can still mix ports and packages with pkgng. Later when we have subpackages you probably will never need to do a specific port build because you want different options. 8. Is there a pkgng equivalent of 'ls -lt /var/db/pkg' without firing up sqlite? Are you looking for the date column (not sure why that's useful as it can change due to many things)? Doesn't pkg info -a suffice? 'ls -lt /var/db/pkg' will show me what packages were installed sorted by day. It is very useful on servers which aren't routinely upgraded to the latest and greatest untested versions There has been discussion to backport creation /var/db/pkg entries and make it readonly. I understand your need because I use that too sometimes. 9. Why didn't pkg upgrade tell me it replaced my custom-built packages? I'd have liked for it to not break stuff when /var/db/ports/*/options differed from the options I can see pkgng keeps in its metadata... You should know by now that mixing ports and packages is
Re: pkg (aka pkgng) 1.0 released
On Aug 30, 2012, at 9:43 AM, John Nielsen li...@jnielsen.net wrote: Thanks to everyone involved. I've been lightly testing pkg for a little while, but I still mainly use ports. This announcement prompted me to switch from portupgrade to portupgrade-devel (20120827 version) to see how it works with PKGNG. I encountered a couple issues: Portupgrade doesn't remove the pkgdb.db.lock reliably. Portupgrade doesn't handle stale lock files (just waits indefinitely for a nonexistent process to finish). A big problem when combined with the above. Running portupgrade pkg failed. It stalled trying to unregister the package installation after the old pkg was removed. I didn't dig too deeply but it seems like a dependency chicken-and-egg problem. I tried this again so I could provide some more details. This is what shows in the terminal when it stalls: --- Backing up the old version --- Uninstalling the old version USING PKGNG --- Deinstalling 'pkg-1.0' --- Preserving /usr/local/lib/libpkg.so.0 as /usr/local/lib/compat/pkg/libpkg.so.0 The following packages will be deinstalled: pkg-1.0 The deinstallation will free 7 MB Deleting pkg-1.0... done [Updating the pkgdb format:bdb_btree in /var/db/pkg ... Running ps in another terminal shows pkg query %n-%v. Since the actual pkg is now gone, I suspect this is really /usr/sbin/pkg. I further suspect that it's waiting for y/n input (whether to install the binary pkg) on its nonexistent stdin somewhere. I killed it (pkg) and portupgrade seemed to finish normally. I was able to reinstall using /usr/sbin/pkg, and I also tested make make deinstall make reinstall of ports-mgmt/pkg successfully, so it may just be a portupgrade issue. JN On Aug 30, 2012, at 8:19 AM, Baptiste Daroussin b...@freebsd.org wrote: After 2 years of development (first commit Tue Sep 7 2010), more than 2000 commits, 43 different contibutors. The pkgng team is proud to release pkg-1.0! [...] Tools supporting natively pkgng - ports-mgmt/portupgrade-devel (soon the main portupgrade will support) [...] ___ freebsd-curr...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: pkg (aka pkgng) 1.0 released
2012/8/30 John Nielsen li...@jnielsen.net: Running ps in another terminal shows pkg query %n-%v. Since the actual pkg is now gone, I suspect this is really /usr/sbin/pkg. I further suspect that it's waiting for y/n input (whether to install the binary pkg) on its nonexistent stdin somewhere. I killed it (pkg) and portupgrade seemed to finish normally. This is the first example where renaming pkg to pkg-bootstrap would have been useful. -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org- against HTML email vCards X www: http://www.gid0.org- against proprietary attachments / \ Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: pkg (aka pkgng) 1.0 released
On 8/30/2012 10:43 AM, John Nielsen wrote: Thanks to everyone involved. I've been lightly testing pkg for a little while, but I still mainly use ports. This announcement prompted me to switch from portupgrade to portupgrade-devel (20120827 version) to see how it works with PKGNG. I encountered a couple issues: Portupgrade doesn't remove the pkgdb.db.lock reliably. Portupgrade doesn't handle stale lock files (just waits indefinitely for a nonexistent process to finish). A big problem when combined with the above. Running portupgrade pkg failed. It stalled trying to unregister the package installation after the old pkg was removed. I didn't dig too deeply but it seems like a dependency chicken-and-egg problem. I was able to reinstall using /usr/sbin/pkg, and I also tested make make deinstall make reinstall of ports-mgmt/pkg successfully, so it may just be a portupgrade issue. Thank you. I'll add some sort of check to prevent this. JN Bryan (portupgrade maintainer) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: pkg (aka pkgng) 1.0 released
On Aug 30, 2012, at 10:06 AM, Olivier Smedts oliv...@gid0.org wrote: 2012/8/30 John Nielsen li...@jnielsen.net: Running ps in another terminal shows pkg query %n-%v. Since the actual pkg is now gone, I suspect this is really /usr/sbin/pkg. I further suspect that it's waiting for y/n input (whether to install the binary pkg) on its nonexistent stdin somewhere. I killed it (pkg) and portupgrade seemed to finish normally. This is the first example where renaming pkg to pkg-bootstrap would have been useful. I think this is a bug in portupgrade, but removing /usr/sbin/pkg does have the side effect of allowing portupgrade to continue (with an empty pkgdb briefly): Deleting pkg-1.0... done [Updating the pkgdb format:bdb_btree in /var/db/pkg ... pkg: not found - 0 packages found (-163 +0) nothing to do] --- Installing the new version via the port ... === Registering installation for pkg-1.0 Installing pkg-1.0... done === Cleaning for pkg-1.0 [Updating the pkgdb format:bdb_btree in /var/db/pkg ... - 163 packages found (-0 +163) 100... done] JN ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Can we please just remove the old Makefile headers?
On Sun, Aug 26, 2012 at 02:02:47PM -0700, Doug Barton wrote: The old Makefile headers, ala: # New ports collection makefile for:BIND 9.9.x # Date created: 27 January 2012 # Whom: dougb # # $FreeBSD: head/dns/bind99/Makefile 301487 2012-07-24 19:23:23Z dougb $ have not served a purpose for longer than almost anyone who has a ports commit bit has been around. My proposal is simple, let's remove everything before the # $FreeBSD$. Traditions are great, particularly when they have meaning. When they just become Doing it that way because we always done it is no substitute for maintaining a tradition for a meaningful purpose. In the past when this has been proposed the objection was that it would cause too much churn. If we had done this back when we had 5,000 ports then we would have solved the problem with less churn, and no drama for the 15,000 ports that followed. Every day we don't do this we make the churn problem worse, and deepen the roots of something that has no relevance. Can we please just deal with this now and be done with it? ... and yes, I am volunteering to help with and/or do the work myself. We discussed this on portmgr@, and we have agreed it is time to make the change. We do request that this be done sparingly in the short term, as we do not want to cause any additional churn on the repo as we approach our upcoming Ports Feature Freeze, still tentatively scheduled for September 7. So please proceed only on existing updates. Please do not do any sweeping commits until we have the ports tree stablised post 9.1 tagging. Also bear in mind that Redports/QAT queues a job for every change done to a Makefile, we do not want to overburden the QAT at this time. It is important to allow this service to run at peek efficiency at this time to ensure it's full potential as we approach the upcoming Feature Freeze. So without further ado, this is what we would like to see at the top of the makefile # # $FreeBSD$ # PORTNAME= It is as easy as that :) Thomas on behalf of portmgr@ Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org -- Thomas Abthorpe | FreeBSD Committer tabtho...@freebsd.org | http://people.freebsd.org/~tabthorpe pgp2TUUaac02a.pgp Description: PGP signature
Re: Can we please just remove the old Makefile headers?
On Thu, Aug 30, 2012 at 3:56 PM, Thomas Abthorpe tabtho...@freebsd.org wrote: On Sun, Aug 26, 2012 at 02:02:47PM -0700, Doug Barton wrote: The old Makefile headers, ala: # New ports collection makefile for:BIND 9.9.x # Date created: 27 January 2012 # Whom: dougb # # $FreeBSD: head/dns/bind99/Makefile 301487 2012-07-24 19:23:23Z dougb $ have not served a purpose for longer than almost anyone who has a ports commit bit has been around. My proposal is simple, let's remove everything before the # $FreeBSD$. Traditions are great, particularly when they have meaning. When they just become Doing it that way because we always done it is no substitute for maintaining a tradition for a meaningful purpose. In the past when this has been proposed the objection was that it would cause too much churn. If we had done this back when we had 5,000 ports then we would have solved the problem with less churn, and no drama for the 15,000 ports that followed. Every day we don't do this we make the churn problem worse, and deepen the roots of something that has no relevance. Can we please just deal with this now and be done with it? ... and yes, I am volunteering to help with and/or do the work myself. We discussed this on portmgr@, and we have agreed it is time to make the change. We do request that this be done sparingly in the short term, as we do not want to cause any additional churn on the repo as we approach our upcoming Ports Feature Freeze, still tentatively scheduled for September 7. So please proceed only on existing updates. Please do not do any sweeping commits until we have the ports tree stablised post 9.1 tagging. Also bear in mind that Redports/QAT queues a job for every change done to a Makefile, we do not want to overburden the QAT at this time. It is important to allow this service to run at peek efficiency at this time to ensure it's full potential as we approach the upcoming Feature Freeze. So without further ado, this is what we would like to see at the top of the makefile # # $FreeBSD$ # PORTNAME= It is as easy as that :) This would make me happy. Another option I would like to throw out there is to just stick the # $FreeBSD$ at the end of the file so the first line is PORTNAME= ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Script to set/unset automatic status in PKGNG database
I today noticed the pkg autoremove command for the first time, which does
much the same thing as pkg_cutleaves but relies on the automatic flag in the
pkgng database rather than user input to determine which leaf ports can be
removed. Unfortunately, the pkg2ng utility has no way of knowing which
old-style packages it converts were installed automatically as dependencies, so
they are all marked as non-automatic (i.e. user-requested). In my case, this
was not true for the majority of installed ports. Since I really like this
functionality, I decided to update my local package database to match my
preferences.
Having succeeded, I decided a tool to make doing so easy could well benefit
others (as well as my future self). (Plus I wanted an excuse to play with
dialog(1) and pkg query a bit.) So here's the result. I'm not too attached to
the name. It shouldn't eat your package database or steal your lunch money, but
I'm not responsible if it does. Other than that, feedback is welcome.
JN
#!/bin/sh
# Copyright (c) 2012 John Nielsen j...@jnielsen.net
# This script presents a checklist of all PKGNG packages registered on
# the system, showing for each whether or not it is marked as automatic
# (i.e. not explicitly requested by the user). Any changes are recorded
# in the PKGNG database. I wrote it to make pkg autoremove useful
# following a pkg2ng migration, but other uses are conceivable.
# The PKGNG database file to use
DB=/var/db/pkg/local.sqlite
# Terminal geometry
sz=`stty size`
rows=`echo ${sz} | cut -d ' ' -f 1`
cols=`echo ${sz} | cut -d ' ' -f 2`
drows=$(( ${rows} - 3 ))
dcols=$(( ${cols} - 6 ))
# Dialog results are stored here
tmpfile=`mktemp -t set_pkg_auto`
# We always want the same style checklist
export DIALOGOPTS=--extra-button --extra-label \Select All\ --cancel-label
\Deselect All\ --help-button --help-label Exit --separator ,
# Exit with an error message
die() {
rm -f ${tmpfile}
echo ${1}
exit 1
}
# Don't leave tmpfile behind even if we are killed/interrupted
trap die \Interrupt received.\ 2 15
# Run dialog to present the checklist and save the results in tmpfile
run_dialog() {
dialog --checklist Select packages to consider for auto-removal
${drows} ${dcols} ${drows} $* 2${tmpfile}
return $?
}
# Show the current status from the package database in the checklist
select_current() {
run_dialog `pkg query '%n %o %a' | sed -e 's/1$/on/g' -e 's/0$/off/g'`
return $?
}
# Select all packages in the checklist
select_all() {
run_dialog `pkg query '%n %o' | sed -e 's/$/ on/g'`
return $?
}
# De-select all packages in the checklist
select_none() {
run_dialog `pkg query '%n %o' | sed -e 's/$/ off/g'`
return $?
}
# Update the package database to match selections in the specified file
do_update() {
autopkgs=`sed -e s/^,//g -e s/\/'/g ${1}`
sqlite3 ${DB} update packages set automatic=1 where name in
(${autopkgs}); \
|| die SQlite error.
sqlite3 ${DB} update packages set automatic=0 where name not in
(${autopkgs}); \
|| die SQlite error.
}
# Run select_current for the first checklist
pkgset=current
# Show the checklist until OK or Exit is selected
while : ; do
select_${pkgset}
case $? in
0) # OK, continue with updates
break;
;;
3) # Extra (Select all), show the checklist again
pkgset=all
;;
1) # Cancel (Deselect all), show the checklist again
pkgset=none
;;
*) # 4-Help (Exit) or ESC or error, exit.
die No changes made.
;;
esac
done
# If we got this far then tmpfile has a list of 'automatic' packages
do_update ${tmpfile}
# Clean up
rm -f ${tmpfile}
echo Updated successfully.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Script to set/unset automatic status in PKGNG database
Thank you,
Would you mind adding create a patch against the git tree of pkgng so that we
can include your script into the scripts subdirectory, so that we provide your
script along with the next pkg 1.0.1 as a contributed script?
regards,
Bapt
On Thu, Aug 30, 2012 at 03:19:59PM -0600, John Nielsen wrote:
I today noticed the pkg autoremove command for the first time, which does
much the same thing as pkg_cutleaves but relies on the automatic flag in
the pkgng database rather than user input to determine which leaf ports can
be removed. Unfortunately, the pkg2ng utility has no way of knowing which
old-style packages it converts were installed automatically as dependencies,
so they are all marked as non-automatic (i.e. user-requested). In my case,
this was not true for the majority of installed ports. Since I really like
this functionality, I decided to update my local package database to match my
preferences.
Having succeeded, I decided a tool to make doing so easy could well benefit
others (as well as my future self). (Plus I wanted an excuse to play with
dialog(1) and pkg query a bit.) So here's the result. I'm not too attached
to the name. It shouldn't eat your package database or steal your lunch
money, but I'm not responsible if it does. Other than that, feedback is
welcome.
JN
#!/bin/sh
# Copyright (c) 2012 John Nielsen j...@jnielsen.net
# This script presents a checklist of all PKGNG packages registered on
# the system, showing for each whether or not it is marked as automatic
# (i.e. not explicitly requested by the user). Any changes are recorded
# in the PKGNG database. I wrote it to make pkg autoremove useful
# following a pkg2ng migration, but other uses are conceivable.
# The PKGNG database file to use
DB=/var/db/pkg/local.sqlite
# Terminal geometry
sz=`stty size`
rows=`echo ${sz} | cut -d ' ' -f 1`
cols=`echo ${sz} | cut -d ' ' -f 2`
drows=$(( ${rows} - 3 ))
dcols=$(( ${cols} - 6 ))
# Dialog results are stored here
tmpfile=`mktemp -t set_pkg_auto`
# We always want the same style checklist
export DIALOGOPTS=--extra-button --extra-label \Select All\ --cancel-label
\Deselect All\ --help-button --help-label Exit --separator ,
# Exit with an error message
die() {
rm -f ${tmpfile}
echo ${1}
exit 1
}
# Don't leave tmpfile behind even if we are killed/interrupted
trap die \Interrupt received.\ 2 15
# Run dialog to present the checklist and save the results in tmpfile
run_dialog() {
dialog --checklist Select packages to consider for auto-removal
${drows} ${dcols} ${drows} $* 2${tmpfile}
return $?
}
# Show the current status from the package database in the checklist
select_current() {
run_dialog `pkg query '%n %o %a' | sed -e 's/1$/on/g' -e 's/0$/off/g'`
return $?
}
# Select all packages in the checklist
select_all() {
run_dialog `pkg query '%n %o' | sed -e 's/$/ on/g'`
return $?
}
# De-select all packages in the checklist
select_none() {
run_dialog `pkg query '%n %o' | sed -e 's/$/ off/g'`
return $?
}
# Update the package database to match selections in the specified file
do_update() {
autopkgs=`sed -e s/^,//g -e s/\/'/g ${1}`
sqlite3 ${DB} update packages set automatic=1 where name in
(${autopkgs}); \
|| die SQlite error.
sqlite3 ${DB} update packages set automatic=0 where name not in
(${autopkgs}); \
|| die SQlite error.
}
# Run select_current for the first checklist
pkgset=current
# Show the checklist until OK or Exit is selected
while : ; do
select_${pkgset}
case $? in
0) # OK, continue with updates
break;
;;
3) # Extra (Select all), show the checklist again
pkgset=all
;;
1) # Cancel (Deselect all), show the checklist again
pkgset=none
;;
*) # 4-Help (Exit) or ESC or error, exit.
die No changes made.
;;
esac
done
# If we got this far then tmpfile has a list of 'automatic' packages
do_update ${tmpfile}
# Clean up
rm -f ${tmpfile}
echo Updated successfully.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
pgpTbAkZ9Z404.pgp
Description: PGP signature
Re: Script to set/unset automatic status in PKGNG database
On 8/30/2012 11:19 PM, John Nielsen wrote: I today noticed the pkg autoremove command for the first time, which does much the same thing as pkg_cutleaves but relies on the automatic flag in the pkgng database rather than user input to determine which leaf ports can be removed. Unfortunately, the pkg2ng utility has no way of knowing which old-style packages it converts were installed automatically as dependencies, so they are all marked as non-automatic (i.e. user-requested). In my case, this was not true for the majority of installed ports. Since I really like this functionality, I decided to update my local package database to match my preferences. Having succeeded, I decided a tool to make doing so easy could well benefit others (as well as my future self). (Plus I wanted an excuse to play with dialog(1) and pkg query a bit.) So here's the result. I'm not too attached to the name. It shouldn't eat your package database or steal your lunch money, but I'm not responsible if it does. Other than that, feedback is welcome. JN You want to use `pkg set -A` :) We make zero promises concerning the SQL schema in pkgng so it can change at every time and break your script. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Script to set/unset automatic status in PKGNG database
On Thu, Aug 30, 2012 at 11:29:14PM +0200, Julien Laffaye wrote: On 8/30/2012 11:19 PM, John Nielsen wrote: I today noticed the pkg autoremove command for the first time, which does much the same thing as pkg_cutleaves but relies on the automatic flag in the pkgng database rather than user input to determine which leaf ports can be removed. Unfortunately, the pkg2ng utility has no way of knowing which old-style packages it converts were installed automatically as dependencies, so they are all marked as non-automatic (i.e. user-requested). In my case, this was not true for the majority of installed ports. Since I really like this functionality, I decided to update my local package database to match my preferences. Having succeeded, I decided a tool to make doing so easy could well benefit others (as well as my future self). (Plus I wanted an excuse to play with dialog(1) and pkg query a bit.) So here's the result. I'm not too attached to the name. It shouldn't eat your package database or steal your lunch money, but I'm not responsible if it does. Other than that, feedback is welcome. JN You want to use `pkg set -A` :) We make zero promises concerning the SQL schema in pkgng so it can change at every time and break your script. ___ freebsd-curr...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org Oh right I missed the sql part :D pgpcQYXS72qcM.pgp Description: PGP signature
Re: Script to set/unset automatic status in PKGNG database
On Aug 30, 2012, at 3:29 PM, Julien Laffaye jlaff...@freebsd.org wrote:
On 8/30/2012 11:19 PM, John Nielsen wrote:
I today noticed the pkg autoremove command for the first time, which does
much the same thing as pkg_cutleaves but relies on the automatic flag in
the pkgng database rather than user input to determine which leaf ports
can be removed. Unfortunately, the pkg2ng utility has no way of knowing
which old-style packages it converts were installed automatically as
dependencies, so they are all marked as non-automatic (i.e. user-requested).
In my case, this was not true for the majority of installed ports. Since I
really like this functionality, I decided to update my local package
database to match my preferences.
Having succeeded, I decided a tool to make doing so easy could well benefit
others (as well as my future self). (Plus I wanted an excuse to play with
dialog(1) and pkg query a bit.) So here's the result. I'm not too attached
to the name. It shouldn't eat your package database or steal your lunch
money, but I'm not responsible if it does. Other than that, feedback is
welcome.
You want to use `pkg set -A` :)
We make zero promises concerning the SQL schema in pkgng so it can change at
every time and break your script.
Thanks. I looked for something like that but not hard enough obviously. I'll
change it.
After dialog(1) exits the script has a list of packages to mark as automatic.
Is there a non-SQL way to efficiently get the inverse? I.e. the set {
all_packages - new_automatic_package_list } ?
JN
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Script to set/unset automatic status in PKGNG database
On Aug 30, 2012, at 3:28 PM, Baptiste Daroussin b...@freebsd.org wrote: On Thu, Aug 30, 2012 at 03:19:59PM -0600, John Nielsen wrote: I today noticed the pkg autoremove command for the first time, which does much the same thing as pkg_cutleaves but relies on the automatic flag in the pkgng database rather than user input to determine which leaf ports can be removed. Unfortunately, the pkg2ng utility has no way of knowing which old-style packages it converts were installed automatically as dependencies, so they are all marked as non-automatic (i.e. user-requested). In my case, this was not true for the majority of installed ports. Since I really like this functionality, I decided to update my local package database to match my preferences. Having succeeded, I decided a tool to make doing so easy could well benefit others (as well as my future self). (Plus I wanted an excuse to play with dialog(1) and pkg query a bit.) So here's the result. I'm not too attached to the name. It shouldn't eat your package database or steal your lunch money, but I'm not responsible if it does. Other than that, feedback is welcome. Would you mind adding create a patch against the git tree of pkgng so that we can include your script into the scripts subdirectory, so that we provide your script along with the next pkg 1.0.1 as a contributed script? No problem. Attached is the output of git diff origin after dropping my script in to my local tree. Let me know if you need something else. Changes between this and the version I originally posted: Added 2-clause license and disclaimer Replaced SQL with 'pkg set' commands. Since I didn't come up with a fast way to list the packages not in the 'automatic' list, I first set all packages to 0 (not automatic), then set the ones in the list to 1. This is likely slower than the SQL variant was, but it's not bad and not something likely to be run frequently. JN set_pkg_auto.sh.diff Description: Binary data ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Script to set/unset automatic status in PKGNG database
On Thu, Aug 30, 2012 at 04:33:09PM -0600, John Nielsen wrote: On Aug 30, 2012, at 3:28 PM, Baptiste Daroussin b...@freebsd.org wrote: On Thu, Aug 30, 2012 at 03:19:59PM -0600, John Nielsen wrote: I today noticed the pkg autoremove command for the first time, which does much the same thing as pkg_cutleaves but relies on the automatic flag in the pkgng database rather than user input to determine which leaf ports can be removed. Unfortunately, the pkg2ng utility has no way of knowing which old-style packages it converts were installed automatically as dependencies, so they are all marked as non-automatic (i.e. user-requested). In my case, this was not true for the majority of installed ports. Since I really like this functionality, I decided to update my local package database to match my preferences. Having succeeded, I decided a tool to make doing so easy could well benefit others (as well as my future self). (Plus I wanted an excuse to play with dialog(1) and pkg query a bit.) So here's the result. I'm not too attached to the name. It shouldn't eat your package database or steal your lunch money, but I'm not responsible if it does. Other than that, feedback is welcome. Would you mind adding create a patch against the git tree of pkgng so that we can include your script into the scripts subdirectory, so that we provide your script along with the next pkg 1.0.1 as a contributed script? No problem. Attached is the output of git diff origin after dropping my script in to my local tree. Let me know if you need something else. Changes between this and the version I originally posted: Added 2-clause license and disclaimer Replaced SQL with 'pkg set' commands. Since I didn't come up with a fast way to list the packages not in the 'automatic' list, I first set all packages to 0 (not automatic), then set the ones in the list to 1. This is likely slower than the SQL variant was, but it's not bad and not something likely to be run frequently. JN Thanks you should be enough, can you provide a git format-patch patch so that you get your name in the logs :D regards, Bapt pgpLl4Jx83qfv.pgp Description: PGP signature
Re: Can we please just remove the old Makefile headers?
On 08/30/2012 09:56 AM, Thomas Abthorpe wrote: So without further ado, this is what we would like to see at the top of the makefile # # $FreeBSD$ # PORTNAME= It is as easy as that :) I was sort of afraid that would be the answer ... while I realize we have massive historical precedents for the additional #s above and below the content, what I was hoping for was that we would make the big break with hysterical raisins and just make the # $FreeBSD$ the first line of the file. It's a minor issue (and yes, this is a legitimate bikeshed) but to my way of thinking the extra #s are just wasted space that reduce the amount of useful data that is presented when you open the file in an editor. I won't lose sleep if we go with the extra #s, but I wanted to at least raise the issue in case there was still a chance to keep it simple. :) Doug ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Can we please just remove the old Makefile headers?
On 08/30/2012 10:09 AM, Steven Kreuzer wrote: This would make me happy. Another option I would like to throw out there is to just stick the # $FreeBSD$ at the end of the file so the first line is PORTNAME= ... also a good suggestion, and further improves the amount of usable data when you first open the file. Doug ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Script to set/unset automatic status in PKGNG database
On Aug 30, 2012, at 4:40 PM, Baptiste Daroussin b...@freebsd.org wrote: Thanks you should be enough, can you provide a git format-patch patch so that you get your name in the logs :D Here you go. 0001-Add-script-to-interactively-set-un-set-automatic-sta.patch Description: Binary data ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: pkgng suggestion: renaming /usr/sbin/pkg to /usr/sbin/pkg-bootstrap
On 08/30/2012 07:32 AM, John Baldwin wrote: On Thursday, August 30, 2012 1:10:24 pm Chris Rees wrote: On 30 Aug 2012 18:03, John Baldwin j...@freebsd.org wrote: On Thursday, August 30, 2012 10:39:17 am Tijl Coosemans wrote: On 27-08-2012 18:24, John Baldwin wrote: On Sunday, August 26, 2012 4:37:53 pm Doug Barton wrote: The problem is that we don't really support the idea of things in the base magically deleting themselves. As I have said in previous messages, the bootstrapping problem is being overblown by several orders of magnitude. For newly installed systems where pkg is the default, /usr/local/bin/pkg will be installed. So there is no bootstrapping problem. For already-installed systems who wish to switch to pkg, they can install from /usr/ports, or use the pkg bootstrap tool in the base. Given that they will be intentionally making this change, and there will be instructions written up on how to do this which include the bootstrapping step, once again this is a non-issue. The whole idea of having every call to /usr/local/sbin/pkg pass through /usr/sbin/pkg in order to help a tiny minority of users with a one-time bootstrapping issue is just plain ludicrous. I agree. Even if we keep /usr/sbin/pkg, we will presumably want to remove it from the base in a year or so via 'make delete-old', etc. Given that, I'm not sure we need it there in the first place. What if you pkg_delete \* or rm -rf /usr/local? Do you have to reboot pkg then? Yes, if we've decided it (pkgng) should not be part of the base. This doesn't strike me as that weird. It seems similar to how one has to bootstrap, say, MacPorts. Difference is, MacPorts isn't the official Mac distribution centre. Leaving out pkg-bootstrap (or whatever) is marginalising ports as a non-integral part of the OS. *sigh* I sadly expected an emotional red herring reply such as this. This has nothing to do with marginalising ports. Prior to this it has been a key argument and point that pkg* should _not_ be tied to the base system as that limits flexibility in the pkg tools. I completely agree with that argument and having /usr/sbin/pkg doesn't appear to be consistent with that. For example, we've already shipped a binary in 9.1 release that has a hardcoded URL of http://pkgbeta.FreeBSD.org;. So now you are stuck keeping that URL around for the next N years, albeit pointing to the production (not-beta) repository. You can't safely reuse pkgbeta.FreeBSD.org for anything until 9.1 is EOL'd. And you'd have to change that before 9.2 and 10.0 if you want to avoid being in the same boat for even longer. That is directly contrary to the goal of having pkg* not being tied to the base. A much more flexible and scalable approach would be for each pkg repository to include a binary/script whatever that you can make available at a URL (which is easily changeable in documentation on our website) that when you run self-extracts and bootstraps pkgng. (The pkg-static stuff is already basically this AFAICT.) If you wish to support existing users of, say, 8.2 or 8.3 release then you need something like this anyway. Also, as a downstream consumer who plans to use a custom pkgng repository on top of a modified FreeBSD distribution, this approach is less failure prone (i.e. if someone runs 'pkg' and it tries to download something from some hardcoded URL that's completely wrong). I agree with John on all counts here. Further, the idea of a self-installing package, at least for the pkg stuff itself, addresses the issue that someone else brought up about how to handle installation of pkg by the installer for a new system. For example it's pretty common in the Linux world to have a package which is wrapped in a shell script which unpacks the tarball, verifies it with a digital signature, then installs the bits from the tarball where they need to go. Since pkg brings a lot of the pieces of this to the party already, it wouldn't be hard to add the rest. ... and please feel free to insert your favorite version of my We have to get away from the idea that something is only good/cool/really part of FreeBSD if it's in the base rant here. :) Doug ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Can we please just remove the old Makefile headers?
On Thu, Aug 30, 2012 at 12:54:17PM -1000, Doug Barton wrote: On 08/30/2012 09:56 AM, Thomas Abthorpe wrote: So without further ado, this is what we would like to see at the top of the makefile # # $FreeBSD$ # PORTNAME= It is as easy as that :) I was sort of afraid that would be the answer ... while I realize we have massive historical precedents for the additional #s above and below the content, what I was hoping for was that we would make the big break with hysterical raisins and just make the # $FreeBSD$ the first line of the file. It's a minor issue (and yes, this is a legitimate bikeshed) but to my way of thinking the extra #s are just wasted space that reduce the amount of useful data that is presented when you open the file in an editor. I won't lose sleep if we go with the extra #s, but I wanted to at least raise the issue in case there was still a chance to keep it simple. :) Doug Well, since we are going with something new, let us just do it, one line # $FreeBSD$ at the very top. Thomas -- Thomas Abthorpe | FreeBSD Committer tabtho...@freebsd.org | http://people.freebsd.org/~tabthorpe pgprfwLM7abWK.pgp Description: PGP signature
Re: Can we please just remove the old Makefile headers?
On Thu, Aug 30, 2012 at 04:09:00PM -0400, Steven Kreuzer wrote: snip So without further ado, this is what we would like to see at the top of the makefile # # $FreeBSD$ # PORTNAME= It is as easy as that :) This would make me happy. Another option I would like to throw out there is to just stick the # $FreeBSD$ at the end of the file so the first line is PORTNAME= I would much rather see it at the top, retaining the notion of header info at the top of the file. We are officially going from six lines down to one, that is buying us (if you still use an 80x24 window like me) an additional 20% of real estate at the top of the editor. Thomas -- Thomas Abthorpe | FreeBSD Committer tabtho...@freebsd.org | http://people.freebsd.org/~tabthorpe pgpSBVqsHks1G.pgp Description: PGP signature
Re: Script to set/unset automatic status in PKGNG database
On 30/08/2012 22:44, John Nielsen wrote:
After dialog(1) exits the script has a list of packages to mark as
automatic. Is there a non-SQL way to efficiently get the inverse?
I.e. the set { all_packages - new_automatic_package_list } ?
Use pkg query - it is really quite powerful. This shows all
non-autoremove packages as name-version:
pkg query -e '%a == 0' '%n-%v'
and this shows the port origin for all autoremove packages:
pkg query -e '%a == 1' '%o'
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil.
PGP: http://www.infracaninophile.co.uk/pgpkey
signature.asc
Description: OpenPGP digital signature
