Re: diff and submissions
On 5/5/17 8:17pm, Mathieu Arnold wrote: > Le 05/05/2017 à 08:16, Franco Fichtner a écrit : >>> On 4. May 2017, at 10:20 AM, Mathieu Arnold <m...@freebsd.org> wrote: >>> >>> If you went as far as being able to create a pull request, you can do a >>> git show HEAD or git diff origin/trunk...HEAD and submit that in the >>> FreeBSD PR as well. >> It's pretty easy to extract the diff from a PR on GitHub, just append >> ".diff", and ".patch" works too, but gives the full git commit history: >> >> https://github.com/freebsd/freebsd-ports/pull/62.diff > > Yes, I am aware of that, the problem with github pull requests is that > they are outside of the FreeBSD bug report process, they do not get > assigned to maintainers, nobody notices them, they just stay there, and > get obsolete. > There have been 61 before, yes, I closed a lot because they were > obsolete because it is outside of our process and nobody noticed them, > and for the rest either asked the submitter to open a PR on our > bugzilla, or opened one myself. > A simple short term workaround might be: 1. Create a pull request template in github [1] 2. Include in it links to bugzilla and instructions for people to create a parallel bug report with a link back to github The main reason I like github is that it is trivial to fork the repository, copy in my patched port files and add comments to the commit. It is considerably more different to remember to create .orig files and then diff them all, bundle it into a shar format and attach to bugzilla. This is all from the perspective of someone who makes a submission once every 3-6 months. Obviously if I had svn commit rights or had even checked out the ports tree from svn then I'd have other options. Most people like me use portsnap so they don't have an svn checkout. Cheers Ari [1] https://help.github.com/articles/creating-a-pull-request-template-for-your-repository/ -- --> Aristedes Maniatis CEO, ish https://www.ish.com.au GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A signature.asc Description: OpenPGP digital signature
diff and submissions
I maintain and couple of ports and I submit patches for others every so often. The process of preparing a patch file is slightly awkward as documented [1] If we want to use the github pull process is that now possible? There are 61 pull requests here: https://github.com/freebsd/freebsd-ports/pulls Ari [1] https://www.freebsd.org/doc/en/books/porters-handbook/port-upgrading.html -- --> Aristedes Maniatis CEO, ish https://www.ish.com.au GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A signature.asc Description: OpenPGP digital signature
Re: ${INSTALL_DATA} problems
My apologies for not explaining in enough detail. On 10/09/2016 10:18pm, Mathieu Arnold wrote: > The plist can be generated automatically with "make makeplist" there is > no way it is hard to do, or maintain. > >> > I really only want one folder installed with the correct permissions, but >> > do I need to move my chmod code into the rc.d startup script instead and >> > tying it into the pkg install? > If it is an empty folder, or you just want the folder itself to have the > permissions, do: > > @dir(%%owner%%,%%group%%,optional mode) the/dir I can see how to use makeplist and to edit the results. However maintaining large lists of files can be cumbersome if you have to manually edit that list every time you upgrade. So I see you have the PLIST_SUB option in Makefile as a way to automatically simplify the plist when it is generated with makeplist. I had also thought from my reading of the Drupal 'uses' makefile that I could use PLIST_FILE += as a way to inject additional lines into the plist when you run makeplist, but it doesn't work like that when I try it. PLIST_FILES+= "@owner www" \ "@group www" \ I also note that the docs [1] indicate that COPYTREE_SHARE doesn't add files to pkg-plist, but I note that for me makeplist does generate them as I'd expect. Maybe it is my misunderstanding of what "add" means. Anyhow, thanks for all your help. The end result of this conversation is: 1. I now know that INSTALL_DATA and COPYTREE_SHARE are two macros which are fairly particular in how they work. One can only do single files and the other requires CD to work correctly. Error messages and portlint don't help much. 2. INSTALL_DATA has switches for user and group, but they should not be used 3. If only a specific folder needs to be owned by a certain user, then it is less effort to add that to a prestart() command in the rc.d script rather than maintaining a plist which is different in one line out of a thousand from the output from makeplist. Many rc.d scripts already do that for /var/run/portname/ or /var/log/portname/ anyhow, so this is an established technique. Cheers Ari [1] https://www.freebsd.org/doc/en/books/porters-handbook/install.html -> 5.15.3 -- --> Aristedes Maniatis GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ 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: ${INSTALL_DATA} problems
On 8/09/2016 10:47pm, Mathieu Arnold wrote: > Now, I'm seeing something else that is a bad idea, it is using the -o > flag. Ports must build as a regular user. A regular user will not be > able to change the owner of the files. This must be done in the > pkg-plist file, using @owner/@group as described in the Porter's > Handbook: > https://www.freebsd.org/doc/en/books/porters-handbook/plist-keywords.html I've just tried this but ran into some difficulty. Specifically I have a plist which is many hundreds of lines long. There is no way this will be maintained into the future without mistake. So I found in Mk/Uses/drupal.mk, this syntx: PLIST_FILES+= "@owner www" \ "@group www" \ When I added this to my Makefile PLIST_FILES+= "@owner {$SOLR_USER}" \ "@group {$SOLR_GROUP}" \ nothing happened. I really only want one folder installed with the correct permissions, but do I need to move my chmod code into the rc.d startup script instead and tying it into the pkg install? Ari -- --> Aristedes Maniatis GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ 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: ${INSTALL_DATA} problems
On 9/09/2016 9:13am, Mark Linimon wrote: > On Fri, Sep 09, 2016 at 08:29:12AM +1000, Aristedes Maniatis wrote: >> Maybe the Makefile language will become clearer to me one day, but >> I've been using FreeBSD since 4.0 and it hasn't clicked yet. > > Don't worry, the FreeBSD ports framework does things with the Makefile > language that was never intended by make's designers :-) > > We do try to document things in the Porter's Handbook, but sometimes > the only thing to do is wade into bsd.port.mk and friends and read the > code. (Not recomended for the faint of heart, though.) I think the most useful thing that could be done is more examples. Even a list of ports which implement things in the recommended ways and do the full range of common things. /var/poudriere/ports/default # grep -R {CP} * | wc -l 1504 So me copying how mariadb101 does it (for example), gives me the wrong result. If I had a dozen "best practices" Makefiles I could copy them. The second most useful thing would be to enhance portlint. Right now it feels like 95% of what it does is enforce some arbitrary ordering of keywords. But if it instead gave you hints "I see you are using {INSTALL_DATA} with a wildcard or directory, instead you should use {COPYTREE_SHARE}" then much time would be saved. Cheers Ari -- --> Aristedes Maniatis GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ 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: ${INSTALL_DATA} problems
Thanks Mathieu On 8/09/2016 10:47pm, Mathieu Arnold wrote: > Like Matthew said, INSTALL_DATA is for installing one file, not a > directory hierarchy, this is done using COPYTREE_SHARE. As a side not, > we never use CP -R to install files. I'm trying to do my best to follow the rules, but the rules are very hard to find. For example if the docs mentioned the one file thing for INSTALL_DATA that would be helpful. Or if the error message was clear... I also don't understand the need for a recursive COPYTREE_SHARE which I believe requires a "cd" first, and a non-recursive INSTALL_*. Maybe the Makefile language will become clearer to me one day, but I've been using FreeBSD since 4.0 and it hasn't clicked yet. > Now, I'm seeing something else that is a bad idea, it is using the -o > flag. Ports must build as a regular user. A regular user will not be > able to change the owner of the files. Then why does INSTALL_DATA have an -o flag at all? I copied this idea from another port I found. > This must be done in the > pkg-plist file, using @owner/@group as described in the Porter's > Handbook: > https://www.freebsd.org/doc/en/books/porters-handbook/plist-keywords.html OK, thanks. I appreciate your help and I'll try your suggestions. Ari -- --> Aristedes Maniatis GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ 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"
${INSTALL_DATA} problems
I'm trying to create a port with a command like this: do-install: ${MKDIR} ${STAGEDIR}${SOLR_HOME} ${INSTALL_DATA} ${WRKSRC}/dist ${STAGEDIR}${SOLR_HOME} However the output is /bin/mkdir -p /var/poudriere/ports/default/textproc/apache-solr/work/stage/usr/local/solr install -m 0644 /var/poudriere/ports/default/textproc/apache-solr/work/solr-5.5.2/dist /var/poudriere/ports/default/textproc/apache-solr/work/stage/usr/local/solr install: /var/poudriere/ports/default/textproc/apache-solr/work/solr-5.5.2/dist: Inappropriate file type or format *** Error code 71 {CP} works fine, but I want to use {INSTALL_DATA} so I can also add the -o flag. What am I doing wrong? Please cc me as I'm not on the list. Thanks Ari -- --> Aristedes Maniatis GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: poudriere with custom packages
On 17/07/2015 3:59pm, Shane Ambler wrote: As long as the name you use for the port is unique, steps like portsnap or svn update should not remove it. I would still keep a copy elsewhere. Thanks for that. I'm doing exactly what everyone here suggests (abandoning my reversing engineered +MANIFEST and using ports) and so far it works well. The only obstacle I found was that adding my own category (to keep out the way of portsnap) didn't work, even with: #cat /usr/ports/Makefile.local SUBDIR += ish CATEGORIES += ish I agree that a weighting on the repo configs would be terrific. Ari -- -- Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A signature.asc Description: OpenPGP digital signature
Re: poudriere with custom packages
Matthew Seaman matt...@freebsd.org wrote: I'd be interested to hear about how you are creating packages outside the ports tree. This is something we'd like to facilitate, but at the moment pkg(8) and the ports are deeply entwined and there isn't much useable documentation or prior art for how to do it 'by hand'. It was pretty much magic, but I pulled apart some existing packages and took a guess at most of it. https://gist.github.com/ari/01eaae67d8c941ccaf68 On the plus side this is a really simple package, nothing complicated. Install a couple of files and a user. Thanks for your two great ideas. I hadn't understood the trick to adding a new ports category, so that makes it much easier if I want to give up my json MANIFEST hack. Please cc me directly, since I'm not on this list. Thanks again for your help! Ari -- -- Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A signature.asc Description: OpenPGP digital signature
poudriere with custom packages
I have a custom built package which I'm building outside the FreeBSD ports system (using pkg-create commands). How can I add that package to a poudriere managed repository so that it appears in the package index and can be easily installed like any other package? Thanks for any help Cheers Ari -- -- Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A signature.asc Description: OpenPGP digital signature
openssl and bash libcrypto
Starting in the last week or so, several different applications are exhibiting the same symptoms of broken libcrypto libraries. (gdb) core bash.core Core was generated by `bash'. Program terminated with signal 11, Segmentation fault. (gdb) bt #0 0x0008029cafe5 in OPENSSL_ia32_cpuid () from /usr/local/lib/libcrypto.so.8 #1 0x0008033cf0b9 in OPENSSL_ia32cap_loc () from /lib/libcrypto.so.7 #2 0x0008032d584e in _init () from /lib/libcrypto.so.7 #3 0x7fffd7c0 in ?? () #4 0x0008006d66bf in r_debug_state () from /libexec/ld-elf.so.1 #5 0x0008006dad87 in _rtld_get_stack_prot () from /libexec/ld-elf.so.1 #6 0x0008006d7ad3 in dlopen () from /libexec/ld-elf.so.1 #7 0x000800e5c436 in _nsdbtaddsrc () from /lib/libc.so.7 #8 0x000800e563c9 in _nsyyparse () from /lib/libc.so.7 #9 0x000800e5cab1 in nsdispatch () from /lib/libc.so.7 #10 0x000800e49ebe in getpwuid () from /lib/libc.so.7 #11 0x000800e49cbf in getpwnam () from /lib/libc.so.7 Although that symptom is in bash, I've got the exact same symptoms in asterisk. The builds are done in poudriere with the make flags: WITH_OPENSSL_PORT=yes I've tried updating to the latest 10.1-RELEASE-p6, although it is possible that that is exactly what caused the problem in the first place when the poudriere jail was updated to that release. The function calls mention ia32 but this box is purely 64bit. I've seen recent discussions about the problems that confusion between core openssl and ports openssl can cause. But I can't for the life of me figure how to avoid this problem. * Should bash be built with Build static executables and/or libraries? * Should I stop trying to use openssl from ports until this is fixed? * Why is /lib/libcrypto.so.7 calling /usr/local/lib/libcrypto.so.8 ? I've tried so many different combinations of settings, I don't know what to try next. Thanks Ari -- -- Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A signature.asc Description: OpenPGP digital signature
Re: +MANIFEST changed syntax in pkg 1.4?
On 22/12/2014 02:43, Aristedes Maniatis wrote: Has the +MAINFEST file changed in sytnax from 1.3 to 1.4 and is now not yaml? I notice that the +MANIFEST files inside packages already built by the ports system look more like json in format. Where do I find documentation for the new format? Matthew Seaman wrote: Yes, +MANIFEST is now generated using libucl -- which uses a JSON-like format. I believe the differences between libucl and JSON are pretty minor (something about comment syntax IIRC) so if you convert your setup to use JSON, it should work. For more information about libucl, start here: https://github.com/vstakhov/libucl Thanks Matthew. Is there any documentation on the new format? I see nothing is updated in the only docs I can find: https://wiki.freebsd.org/pkgng#Package_format I guess I'm really not understanding pkgng... I've used FreeBSD since version 4 but this is the first time I've seen something in the core system so undocumented and with so many regressions compared to the previous tools. I really wish we could go back to pkg_ Thanks Ari -- -- Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ 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
+MANIFEST changed syntax in pkg 1.4?
Ever since we upgraded to pkg 1.4, our scripts which create packages from binary applications are now failing. I use pkg create to generate a pkg from a folder full of files. The +MAINFEST file is something we create from a template. Since the upgrade, we are unable to create packages. Note that we don't use ports since we aren't building from source, but just creating convenient installers for FreeBSD systems. The error we get looks like this: pkg: manifest parsing error: error while parsing unknown: line: 31, column: 8 - 'invalid character in a key', character: '0x0a' But at the line number in question is nothing out of the ordinary. Just the lines after: scripts: pre-install: |- if I completely get rid of the scripts section, then I get another set of errors like: pkg: Skipping malformed key 'version' pkg: Skipping malformed key 'deps' pkg: Skipping malformed key 'files' Has the +MAINFEST file changed in sytnax from 1.3 to 1.4 and is now not yaml? I notice that the +MANIFEST files inside packages already built by the ports system look more like json in format. Where do I find documentation for the new format? Thanks Ari Maniatis -- -- Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ 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 MANIFEST documentation
On 14/03/13 6:50pm, Baptiste Daroussin wrote: On Thu, Mar 14, 2013 at 06:34:31PM +1100, Aristedes Maniatis wrote: 1. What is the syntax of deps when I want to depend on Java, but not specify the version? I've tried this: deps: javavmwrapper: {origin: java/javavmwrapper} Here name and version are mandatory, this is to allow pkg add (used by the ports tree, tinderbox and pointyhat) to be able to look at a package around the package you want to install when doing pkg add ./yourpkg.txz it will try to get ./javawrapper-version.txz if exists. Compatibility needed. So effectively it is impossible to build a package outside of the machine on which you are targeting? (or a controlled build farm like poudriere where everything is always the most recent version). I want the package to require only Java but instead I have to specify exactly the version of every dependency. Which of course I cannot know. I don't see how this relates to pkg -o oldorigin:neworigin. In that case you only need to use -o if the dependency name changes, not the version. If I just use the oldest compatible version of javavmwrapper, I assume pkg will happy cope with a newer version of javavmwrapper installed? Secondly, I am confused by the tar packaging itself. It appears that my package only works if I build it using tar Pf packge.tar / Why are you trying to pack using tar and not pkg create directly? In this case because I am performing the build on a server which isn't FreeBSD. And I figured How hard would it be to just write out the MANIFEST file and tar/xz up the result. The answer is Very hard. For what it is worth, I didn't need to do this when I assembled the old pkg_ format by hand. It worked happily with relative paths. Is this change in requiring absolute paths a bug or a new feature? Is the correct way to chroot to a folder, assemble all the files relative to root and then tar in this way? Again, why doesn't pkg cope with relative tar pathing? Isn't that the whole point of 'prefix'? Not at all package without prefix is broken by design because 90% of the binaries will have hardcoded prefix. To install respecting chroot just pkg -c /mychroot/ install mypkg This confuses me. The FreeBSD ports system does not respect 'prefix'? I thought that was a critical feature (although I don't personally use it). If this is broken by design, why do you have prefix as an option in the MANIFEST? Why is pkg making the breakage mandatory? When the binary package repository is brought back on line (I understand it is still dead after the hacking problem) will it not support prefix at all? regards, Bapt Thanks Ari -- -- Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ 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 MANIFEST documentation
On 14/03/13 7:31pm, Chris Rees wrote: Packages never supported PREFIX. You can change PREFIX in ports, at compile time, but once the compilation is done, changing PREFIX will break many compiled binaries. OK, good to know thanks. So this change from relative tar packaging (pkg_) to absolute paths (pkgng) is a way of ensuring that packages are never portable? I still don't understand the prefix attribute in MANIFEST. I guess it should be removed? Ari -- -- Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ 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
Share /var/cache/pkg/ between machines
I'd like to share packages between a couple of nearly identical machines in a server farm. I think I have the following options: 1. Set up apache httpd on one primary machine to serve the packages to the others by pointing website root to to /var/cache/pkg/ and setting PACKAGESITE in the other servers. This looks like it might work except that repo.txz is missing from /var/cache/pkg/ 2. rsync /var/cache/pkg/ from the primary machine to the others. Set PACKAGESITE on all machines to point to some central repository where all these packages originally were built (we run poudriere in another location). 3. Something else How do other people cache/proxy built packages under pkgng? I don't want to have to pull the same 80Mb JDK package onto 10 machines across the internet. Thanks Ari -- -- Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ 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: Share /var/cache/pkg/ between machines
On 26/02/13 5:22pm, Alexander Yerenkow wrote: I don't understand how do you imagine magical appearing 80 Mb JDK from any one place to other without pulling data from internet? :) In any case, with any kind of sharing you probably will have almost same traffic, maybe even greater than if you choose simple `pkg install` traffic. Perhaps I oversimplified our setup. Here is what we have: - pkg.office.example.com (poudriere): builds all packages (pkgng). Runs apache to serve repository to other servers. -- server1.office.example.com pulls files from build server (PACKAGESITE points to pkg.office.example.com) -- server2.office.example.com, etc.. as above office -- VPN tunnel -- colo (data centre) - pkg.colo.example.com also pulls files from build server (PACKAGESITE points to pkg.office.example.com) -- server[2-10].colo.example.com... rather than pull packages over the slow VPN tunnel, I want to pull them from pkg.colo.example.com Now, one approach is to rsync the poudriere output folder on pkg.office.example.com to pkg.colo.example.com. And given the complexity of other options, that's probably what I'll do. It means more network traffic than optimal, because poudriere will bulk many packages which aren't actually needed in the colo (and more often than the colo machines are actually updated as well since poudriere in the office might do a run twice a week, but the colo is updated once every 3 months or when there is a security patch we care about). So I was hoping to rely on pkg install to pull the package over the VPN network, and then replicate the data out to the other servers (NFS/rsync/etc) in the colo. Sorry for confusing you with my abbreviated problem description. Hopefully this is clearer. Ari 1 - pointless, you can set up simple nginx, pointing to poudriere build packages directory and set up packagesite in /u/l/e/pkg.conf, without any proxy machine, which must download these cached packages in any case to be served by apache. AFAIK that machine will download something only while installing, right? So you overcomplicate your setup. 2. rsync will produce packagesize traffic + constant little more, due to checks of alteration. You'll lose in that case in long shot. My advice - put nginx to serve poudriere's built packages dir, and trust to xz compression level = easy to setup, not big traffic really. This is of course based on sentence ... onto 10 machines across the internet - if you have some clusters with PCs in some nets, then you could think about rsync with primary poudriere, to serve locally packages for few other PCs. Hope this help :) -- Regards, Alexander Yerenkow -- -- Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ 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: portmaster cannot find package
On 20/05/10 10:35 AM, Doug Barton wrote: On 05/19/10 17:19, Jurgen Weber wrote: Dough Ah, I see. That looks to have worked correctly. Excellent! Hi Doug Can I suggest a note in the man page about this. For many users this is likely the first time they would hit this discrepancy with the INDEX files and portsnap. Your index-only feature is certainly the first time we hit this issue. Until now we never knew that INDEX was built conditionally around the settings in make.conf, and we've been using FreeBSD ports for about 15 years now. --index-only do not try to use /usr/ports. For updating ports when no /usr/ports directory is present the -PP|--packages-only option is required. See the ENVIRONMENT section below for additional requirements. When using this feature with any options that affect port building in make.conf, make sure you build your INDEX files with 'make index' rather than using the portsnap supplied INDEX files. Thanks for all your great work on the portmaster tool. Ari -- -- Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ 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: portmaster cannot find package
On 17/05/10 3:49 PM, Doug Barton wrote: On 05/16/10 20:35, Aristedes Maniatis wrote: On 5/05/10 1:54 AM, Doug Barton wrote: Is there an apache-2.2.13 package in packages/All? And what do the links in packages/www and packages/Latest refer to? I did some more digging in the script itself. You have some code like this: if [ -r ${LOCAL_PACKAGEDIR}/All/${new_port}.tbz ]; then local_package=${LOCAL_PACKAGEDIR}/All/${new_port}.tbz latest_pv=${local_package##*/} fi But I'm guessing the confusion is that we have /Latest/apache22.tgz, but ./All/apache-worker-2.2.15.tgz No, the Latest doesn't enter into it with --index-only. Perhaps I've confused the threads. But this issue appears to be a simple one: I've installed the www/apache22 port but with certain settings it installs the package called apache-worker. And with the index-only option, it thinks it can see 2.2.13 but that version package doesn't even exist in /All. I'm assuming that ${new_port} is confused between the real package name and the 'other' name, but that could be an incorrect guess on my part. Certainly the problem goes away if I remove the index-only option from portmaster.rc. I've also tried using portsnap fetch update to update to a current INDEX file. If /Latest isn't being used, and portmaster is using the reference in the INDEX file to know which package to try and install, it is certainly finding the right version number, but just failing to find the package I can see sitting right there in /All. Regards Ari -- -- Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ 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: portmaster cannot find package
On 17/05/10 4:17 PM, Doug Barton wrote: The INDEX has to be generated with the same settings as the packages were created with. Well, before we tried to run portsnap to update it, we also just copied /usr/ports/INDEX* from the build machine to the production server. We tried portsnap since we thought that might be copying corrupted files. Ari -- -- Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ 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: portmaster cannot find package
On 5/05/10 1:54 AM, Doug Barton wrote: Is there an apache-2.2.13 package in packages/All? And what do the links in packages/www and packages/Latest refer to? I did some more digging in the script itself. You have some code like this: if [ -r ${LOCAL_PACKAGEDIR}/All/${new_port}.tbz ]; then local_package=${LOCAL_PACKAGEDIR}/All/${new_port}.tbz latest_pv=${local_package##*/} fi But I'm guessing the confusion is that we have /Latest/apache22.tgz, but ./All/apache-worker-2.2.15.tgz That is, the package name is different between Latest and All. This particular code path is only invoked if you are using INDEX rather than the ports directories. When running without forcing the index, the problem does not occur. I like the INDEX-only approach since we can have deployment servers with no /usr/ports directories to keep updated. A special build server is responsible for creating packages and pushing them out to other machines. Ari -- -- Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ 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: portmaster cannot find package
On 5/05/10 1:54 AM, Doug Barton wrote: On 5/4/2010 3:09 AM, Aristedes Maniatis wrote: portmaster.rc # Always delete stale distfiles without prompting (-d) ALWAYS_SCRUB_DISTFILES=dopt # Only install packages (-PP or --packages-only) PM_PACKAGES=only # Use the INDEX file instead of /usr/ports (--index-only) PM_INDEX=pm_index PM_INDEX_ONLY=pm_index_only # Specify a local package repository (--local-packagedir) LOCAL_PACKAGEDIR=/usr/ports/packages/ This all looks proper. Trying to run an update: [snip...] === Checking package repository for latest available version === The newest available package (apache-2.2.13) is older than the version in ports (apache-2.2.14_6) #ls -al /usr/ports/packages/All/apache-worker-2.2.14_6.tbz -rw-r--r-- 1 root wheel 3032918 May 3 21:06 /usr/ports/packages/All/apache-worker-2.2.14_6.tbz Is there an apache-2.2.13 package in packages/All? And what do the links in packages/www and packages/Latest refer to? No package named that in All. Just the *-worker variant. /usr/ports/packages # ls -al www/apache-worker-2.2.14_6.tbz lrwxr-xr-x 1 root wheel 33 May 3 13:04 www/apache-worker-2.2.14_6.tbz - ../All/apache-worker-2.2.14_6.tbz /usr/ports/packages # ls -al Latest/apache22.tbz lrwxr-xr-x 1 root wheel 33 May 3 13:04 Latest/apache22.tbz - ../All/apache-worker-2.2.14_6.tbz I just hit a pretty similar problem with the package ImageMagick-nox11-6.6.0.10.tbz for I assume the same reason. Ari -- -- Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ 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
portmaster cannot find package
portmaster.rc # Always delete stale distfiles without prompting (-d) ALWAYS_SCRUB_DISTFILES=dopt # Only install packages (-PP or --packages-only) PM_PACKAGES=only # Use the INDEX file instead of /usr/ports (--index-only) PM_INDEX=pm_index PM_INDEX_ONLY=pm_index_only # Specify a local package repository (--local-packagedir) LOCAL_PACKAGEDIR=/usr/ports/packages/ Trying to run an update: [snip...] === Checking package repository for latest available version === The newest available package (apache-2.2.13) is older than the version in ports (apache-2.2.14_6) === Try --packages-if-newer, or do not use -PP/--packages-only === Aborting update === Update for apache-worker-2.2.14_6 failed === Aborting update #ls -al /usr/ports/packages/All/apache-worker-2.2.14_6.tbz -rw-r--r-- 1 root wheel 3032918 May 3 21:06 /usr/ports/packages/All/apache-worker-2.2.14_6.tbz But sometimes it works. Ari -- -- Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ 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: portmaster and IGNOREME
On 26/04/10 8:55 AM, Doug Barton wrote: I've just committed a fix for this problem to the svn (development) version of portmaster. You can find information on how to download it at http://dougbarton.us/portmaster-proposal.html. I would appreciate it if you would test that version in your environment to confirm that the fix is satisfactory. Firstly, it looks like it is unable to run with a relative path. Pretty minor issue, but I thought I'd mention it. # fetch http://svn.freebsd.org/base/user/dougb/portmaster/portmaster # sh ./portmaster -ai === Gathering distinfo list for installed ports === Starting check of installed ports for available updates === Checking ports for recursive 'make config' === Update bacula-client-3.0.3 to bacula-client-5.0.0? y/n [y] y === Launching child to update bacula-client-3.0.3 to bacula-client-5.0.0 ./portmaster: ./portmaster: not found === Update for bacula-client-3.0.3 failed === Aborting update But when using an absolute path # sh /root/portmaster -ai it works just nicely. There are still small oddities: * I get the list of ports to upgrade, then Proceed y/n, and after that it sees CGatePro and tries to upgrade it. That is, the package is presented after the list of ports is already shown and the user asked to proceed. Shouldn't they be all together? If I say n then I never even see the messages about the package with no ORIGIN. * when using portmaster -ai I'm still given a choice to upgrade the package with no ORIGIN. But why ask since we already know it will fail 100% of the time? 99.9% of the time, not having an ORIGIN in the +CONTENTS file is an error that requires user attention. You are the expert in this area, but I don't agree about the 0.01% usage of packages. Isn't missing ORIGIN going to be the case for every package which isn't installed from ports? Anyhow, thanks for the fixing the problem so quickly: all the comments above are very minor and are more for feedback than because I expect you to do anything. Regards Ari -- -- Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ 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: portmaster and IGNOREME
On 25/04/10 6:38 AM, Doug Barton wrote: On 04/23/10 22:43, Aristedes Maniatis wrote: I have a package which is not built from a port (it is commercial software). I've put an +IGNOREME file in the package folder. But portmaster will not ignore it: #portmaster -a [snip...] === Proceed? y/n [y] === Starting build for for ports that need updating=== === Launching child to update CGatePro-5.3.5 === No ORIGIN in /var/db/pkg/CGatePro-5.3.5/+CONTENTS === Aborting update === Update for CGatePro-5.3.5 failed === Aborting update I'd like to add one more point about this, which might be separate to the issue about +IGNOREME. portmaster -a compiles a list of all the ports it will upgrade or install and asks if you want to proceed. CGatePro is only examined AFTER that point. It does not appear in the list before the Proceed? y/n question. In this case, since it is a package and not a port, why does portmaster look at it at all? There is no useful information available about whether it can be upgraded (I'm not running with -P). I don't really want to have to put IGNOREME in that package... I only did that to try and make portmaster ignore something it should already be ignoring. Perhaps your improvements to ORIGIN handling will also deal with this. Thank you for a great tool. Regards Ari -- -- Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ 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: portmaster and IGNOREME
On 25/04/10 11:37 AM, Doug Barton wrote: On 04/24/10 16:26, Aristedes Maniatis wrote: I'd like to add one more point about this, which might be separate to the issue about +IGNOREME. portmaster -a compiles a list of all the ports it will upgrade or install and asks if you want to proceed. CGatePro is only examined AFTER that point. It does not appear in the list before the Proceed? y/n question. What is your exact portmaster command line, and do you have anything in a portmaster rc file? portmaster -a and the only config is ALWAYS_SCRUB_DISTFILES=dopt I also tried with -ai in order to exclude the problem package, but your -x suggestion is even better. In this case, since it is a package and not a port, why does portmaster look at it at all? The -a option looks at everything /var/db/pkg. Sure. And this package exists there. But without an origin to point it back to a port directory, hopefully this package should be completely ignored by '-a'. If you want to play with this particular example on your system, you can grab it from here: ftp://ftp.stalker.com/pub/CommuniGatePro/5.2/ Quite a nice mail server, and installing it doesn't scatter files all over the place so it is quite safe to try installing. The licensing only comes into play if you add more than 10 mail boxes. Ari -- -- Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ 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
portmaster and IGNOREME
I have a package which is not built from a port (it is commercial software). I've put an +IGNOREME file in the package folder. But portmaster will not ignore it: #portmaster -a [snip...] === Proceed? y/n [y] === Starting build for for ports that need updating === === Launching child to update CGatePro-5.3.5 === No ORIGIN in /var/db/pkg/CGatePro-5.3.5/+CONTENTS === Aborting update === Update for CGatePro-5.3.5 failed === Aborting update Unless there is some clear documented reason, portmaster should ignore ports which are marked to be ignored. The documentation reads: If you do a regular update of the port, or if the -a option is being used you will be asked if you want to update the port anyway. I am not being asked, it just fails the entire port upgrade process, unless I use -ia and specifically exclude this package. I don't know enough about package files to know why ORIGIN is required, even for packages which aren't generated from the ports system. Ari -- -- Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ 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: [ HEADS UP ] Ports unstable for the next 10 days
On 29/03/10 7:04 PM, Doug Barton wrote: portmaster -r graphics/png That won't work, the man page clearly says that it has to be a port directory or glob pattern from /var/db/pkg. The glob pattern bit of that was (unfortunately) broken up till version 2.20, which I just committed. I'm confused. The manual actually says: [-R] -r name/glob of port in /var/db/pkg When I try your suggestion I get this: # portmaster -r png- === No valid installed port, or port directory given === Try portmaster --help And this doesn't work either: # portmaster -r graphics/png === No valid installed port, or port directory given === Try portmaster --help So, as you say the pkg pattern is broken, but also 'port directory' doesn't work either unlike your suggestions above. It would be nice for both pkg and directory patterns to be more consistently available, but in the meantime readers of UPDATING are going to be confused. Ari Maniatis -- -- Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ 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