You can subscribe to this list here.
2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(8) |
Sep
(4) |
Oct
(1) |
Nov
(4) |
Dec
(2) |
2011 |
Jan
(4) |
Feb
(2) |
Mar
(2) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
(6) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
2012 |
Jan
|
Feb
(1) |
Mar
(2) |
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(3) |
From: Jae P. <jp...@yp...> - 2014-12-31 02:22:59
|
Thank you for your input. But I ended up with adding: $: << '/usr/lib/ruby/site_ruby/1.8' if RUBY_VERSION >= '1.9' at the beginning of the executable using our internal build script. I don’t really like it, but it allows us to use one RPM file for all versions of CentOS. And it seems to be the simplest solution. I’m not sure if this kind of workaround is acceptable in upstream. If you think it’s OK, I’ll submit a pull request. Otherwise I’ll just keep it in our internal build script. Happy New Year! Jae Park From: Jason Heiss <jh...@ap...<mailto:jh...@ap...>> Date: Friday, December 19, 2014 at 3:40 AM To: Jae Park <jp...@yp...<mailto:jp...@yp...>> Cc: "tpk...@li...<mailto:tpk...@li...>" <tpk...@li...<mailto:tpk...@li...>> Subject: Re: [tpkg-users] Ruby site_ruby location in CentOS 7 Yeah, to me it seems like the right thing to do is to move the current rpm rake task and spec file to “oldrpm” or something and replace them with a new task/spec that puts files in the new location. On Dec 18, 2014, at 8:08 PM, Jae Park <jp...@yp...<mailto:jp...@yp...>> wrote: Hi, We’re having a problem in making tpkg client work in CentOS 7. It seems the default site_ruby directory has changed from "/usr/lib/ruby/site_ruby" to "/usr/local/share/ruby/site_ruby” in Ruby 2.0.0 of CentOS 7.0 yum base repo. Should we just accept the change and have the build script create multiple RPM packages, or is there a better solution? Thank you. Jae Park ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk_______________________________________________<https://urldefense.proofpoint.com/v2/url?u=http-3A__pubads.g.doubleclick.net_gampad_clk-3Fid-3D164703151-26iu-3D_4140_ostg.clktrk-5F-5F-5F-5F-5F-5F-5F-5F-5F-5F-5F-5F-5F-5F-5F-5F-5F-5F-5F-5F-5F-5F-5F-5F-5F-5F-5F-5F-5F-5F-5F-5F-5F-5F-5F-5F-5F-5F-5F-5F-5F-5F-5F-5F-5F-5F-5F&d=AwMF-g&c=lXkdEK1PC7UK9oKA-BBSI8p1AamzLOSncm6Vfn0C_UQ&r=dhTobnpgvRHcgyLkp_MAuA&m=Sf2jxjZI9oG3DWsSf7DV6793d5sV0MaepDgFqrxUePI&s=8gSOA3C0SEUcVtnGfOa8REOx-VrGxbJUuaJ_VNPaLL8&e=> tpkg-users mailing list tpk...@li...<mailto:tpk...@li...> https://lists.sourceforge.net/lists/listinfo/tpkg-users |
From: Jason H. <jh...@ap...> - 2014-12-19 11:56:56
|
Yeah, to me it seems like the right thing to do is to move the current rpm rake task and spec file to “oldrpm” or something and replace them with a new task/spec that puts files in the new location. > On Dec 18, 2014, at 8:08 PM, Jae Park <jp...@yp...> wrote: > > Hi, > > We’re having a problem in making tpkg client work in CentOS 7. > It seems the default site_ruby directory has changed from "/usr/lib/ruby/site_ruby" to "/usr/local/share/ruby/site_ruby” in Ruby 2.0.0 of CentOS 7.0 yum base repo. > Should we just accept the change and have the build script create multiple RPM packages, or is there a better solution? > Thank you. > > Jae Park > > ------------------------------------------------------------------------------ > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & more > Get technology previously reserved for billion-dollar corporations, FREE > http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk_______________________________________________ > tpkg-users mailing list > tpk...@li... > https://lists.sourceforge.net/lists/listinfo/tpkg-users |
From: Jae P. <jp...@yp...> - 2014-12-19 01:25:18
|
Hi, We’re having a problem in making tpkg client work in CentOS 7. It seems the default site_ruby directory has changed from "/usr/lib/ruby/site_ruby" to "/usr/local/share/ruby/site_ruby” in Ruby 2.0.0 of CentOS 7.0 yum base repo. Should we just accept the change and have the build script create multiple RPM packages, or is there a better solution? Thank you. Jae Park |
From: Jason H. <jh...@ap...> - 2012-04-05 20:04:22
|
This release fixes the sudo problem (which most obviously manifested as a locking problem) in 2.3.1. |
From: Jason H. <jh...@ap...> - 2012-04-05 18:41:53
|
After upgrading my laptop to 2.3.1 I'm seeing tpkg have problems with the locking mechanism. So y'all might want to hold off on upgrading until I get that figured out. On Apr 5, 2012, at 2:00 PM, Jason Heiss wrote: > Add -H to sudo command line options in case sudo is configured with both env_reset and always_set_home turned off. (env_reset is on by default.) Requested by Frank Maritato. > > Add a "sudo" setting to tpkg.conf. This allows you to override tpkg's default notion of when to use sudo. For example, if you configure a tpkg base in your home directory you may not want tpkg to use sudo. > > Remove -w from ruby flags in all executables. It is hard to eliminate warnings from gems and other libraries that we use, making the warnings annoying. > > ------------------------------------------------------------------------------ > Better than sec? Nothing is better than sec when it comes to > monitoring Big Data applications. Try Boundary one-second > resolution app monitoring today. Free. > http://p.sf.net/sfu/Boundary-dev2dev_______________________________________________ > tpkg-users mailing list > tpk...@li... > https://lists.sourceforge.net/lists/listinfo/tpkg-users |
From: Jason H. <jh...@ap...> - 2012-04-05 18:01:18
|
Add -H to sudo command line options in case sudo is configured with both env_reset and always_set_home turned off. (env_reset is on by default.) Requested by Frank Maritato. Add a "sudo" setting to tpkg.conf. This allows you to override tpkg's default notion of when to use sudo. For example, if you configure a tpkg base in your home directory you may not want tpkg to use sudo. Remove -w from ruby flags in all executables. It is hard to eliminate warnings from gems and other libraries that we use, making the warnings annoying. |
From: Jason H. <jh...@ap...> - 2012-03-26 23:28:28
|
On Mar 26, 2012, at 6:11 PM, Dave Yu wrote: > Is there a proper process for removing a tpkg from a repository? No: http://sourceforge.net/apps/trac/tpkg/ticket/16 > We have an accidentally uploaded tpkg causing problems because the version number is newer than it should be. Is it safe to just delete the file from the repository server? Yes, you can just delete it from the repository and re-run tpkg -x. The reason we're somewhat cautious about allowing easy deletes is that users tend to abuse it for cases where they should just bump the version number. I.e. a bad use case for deleting a package is: * User releases foo-1.0-1.pkg * User realizes 1.0-1 is broken * User wants to delete 1.0-1 and replace it with a correct package The user should just release 1.0-2, but novice packagers are often reluctant to leave broken versions in the repository. A good use case is the case you have where the version number is completely bogus, the package hasn't been available for very long so few, if any, users will have picked it up, etc. In that case the right thing is to delete the bogus package and release a correct version. In my experience that is infrequent enough that we just made it a manual operation, track down a tpkg admin and ask them to delete the package manually. However I would like this to be supported functionality at some point in the future. Jason |
From: Dave Yu <dy...@at...> - 2012-03-26 22:11:49
|
Is there a proper process for removing a tpkg from a repository? We have an accidentally uploaded tpkg causing problems because the version number is newer than it should be. Is it safe to just delete the file from the repository server? Thanks, Dave |
From: Jason H. <jh...@ap...> - 2012-02-01 12:43:08
|
(Moving this to tpkg-users since that seems more appropriate for this thread, bcc out tpkg-devel) On Dec 23, 2011, at 4:45 PM, patrick o'leary wrote: > Finally with nobody in the office, got a chance to try latest tpkg code with cygwin changes > Noticed a couple of things > > 1) tpkg doesn't like a base of 'tmp', even when I make the tmp dir in my home directory, reference it as --base=tmp or ./tmp tpkg seems to go on a road trip to find something else? Works if i use a different directory name. Weird. The base directory has to be a fully qualified path. Internally tpkg File.joins it with '/' [1] so 'tmp' and './tmp' both become '/tmp'. I've now documented this in the tpkg.1 man page. [1] The reason for this is that instead of '/' it might be some other directory as specified via the --test-root switch. '/' just happens to be the default value for the "root" directory if --test-root isn't specified. This is used by the tpkg test suite to run tpkg without any interaction with any standard tpkg installation on the test system. I.e. with --test-root we read <test-root>/etc/tpkg.conf instead of /etc/tpkg.conf, etc. > 2) Also dnsdomainname from facter doesn't work on cygwin, but if you symlink hostname to dnsdomainname on your path, the error goes away, but still doesn't report the right server name back to the reporting server. I held onto this email for a long time thinking I'd look into this, but clearly I'm not getting the time to do so, so I'm going to punt and say if you figure out how to fix this let me know. Jason |
From: Jason H. <jh...@ap...> - 2011-12-14 14:38:33
|
New Features ------------ --qi/--ql/--qr/--qd now only query installed packages. Add --qis, --qls, --qds, --qXs switches to query packages on server. --qld removed since --qd now has that behavior. --ql now shows if files in uninstalled packages are relocatable. Cleaned up --qi formatting. Query switches now report errors to stderr instead of stdout. --qv becomes --qs, --qva becomes --qas, old switches are deprecated. Removed currently installed packages from --qs/--qas output. Add --group option so that the user can specify groups of servers rather than individual hostnames (as with --servers). Expanding the groups is up to a user-provided script defined in the config file via the host_group_script option. See tpkg(1) man page for more details. Add --skip_remove_stop option. tpkg normally runs any init scripts with a "stop" argument on package removal. This option prevents that behavior. The init script might be known to be broken, etc. Add version inequality support on the command line. Things like "tpkg -i foo>=2.4" will now work Tpkg now nearly passes its test suite under cygwin. The only two test failures are due to the facter library spitting out some warnings on stderr that trigger failures in the command line options testing due to unexpected output. Add the path to tar to the output of "tpkg --qenv". Users might want to check which copy of tar tpkg has found to use. Bug fixes and Enhancements -------------------------- Fix problem with MANPATH value introduced in 2.2.4 which excluded system man directories from the search. Fix encrypting and decrypting empty files. Thanks to vpkaihla for the patch. Apparently different versions of ruby have OpenSSL::CipherError or OpenSSL::Cipher::CipherError. Thanks to vpkaihla for the patch. cpan2tpkg now preserves permissions on files. Thanks to Erik S. Chang for the patch. When packaging gems that are dependencies of the gem that the user requested gem2tpkg will no longer add the user's extra dependencies. gem2tpkg will only add the extra dependencies to the gems the user requested. Provide a better error message if the user specifies a non-existent source directory or relative URI as a source. Tpkg will no longer be confused if you query for a package name and a directory with the same name exists in your current working directory. Fix bug where we were skipping externals when the user installed a package for the first time using the "upgrade" method. Reported by Erik S. Chang. Change specification of --compress switch to syntax that makes the equals sign optional when specifying an argument. Turn off sudo by default on Windows (cygwin or rubyinstaller). Modify the definition of the --no-sudo switch so that it can be called as --sudo to turn sudo back on for those platforms (Windows) where it is off by default. Suggested by Patrick O'Leary. Under cygwin File.chown raises Errno::EINVAL. Ignore it. Reported by Patrick O'Leary. Server no longer requires authentication by default. Thanks to Darren Dao for the change. |
From: Ian Y. <Ian...@me...> - 2011-08-10 01:32:03
|
Oops, disregard that last message. I accidentally installed the wrong revision number that time. The postinstall script works so that will solve the problem for now, but I can't figure out what's overwriting the directory attributes after tpkg.yml is applied but before the postinstall script is run. From: Ian Young [mailto:Ian...@me...] Sent: Tuesday, August 09, 2011 6:24 PM To: tpk...@li... Subject: Re: [tpkg-users] directory permissions not persisting I tried creating a postinstall script to run chown apache on 3 directories but that didn't have any effect. I put it at the same level as the tpkg.yml file and gave it execute permission. After installation the directories were still owned by the user specified in the tpkg.yml file. Could there be anything that runs after the postinstall script? From: Ian Young [mailto:Ian...@me...] Sent: Monday, August 08, 2011 5:36 PM To: tpk...@li... Subject: Re: [tpkg-users] directory permissions not persisting The simple packages I create work as expected; it's the actual package to be used for production that has issues and, unfortunately, that can't be disseminated. There is no postinstall directory for this package. I modified the file_defaults in the yml file to see if it was respecting those settings. I changed owner to root and perms to 0650. Everything ended up owned by root, however, the 0650 permissions were only applied to files, not directories. Directory permissions were set to 0755. From: Darren Dao [mailto:dar...@gm...] Sent: Monday, August 08, 2011 5:01 PM To: Ian Young Cc: tpk...@li... Subject: Re: [tpkg-users] directory permissions not persisting I can't reproduce the problem using the yml files you provided. I used the tpkg-prod.yml file you attached and create a test package from it (see attachment). Here's my output ck3.np.dc1.eharmony.com<http://ck3.np.dc1.eharmony.com> $ tar xvf mypackage2.tar mypackage2/ mypackage2/root/ mypackage2/root/var/ mypackage2/root/var/www/ mypackage2/root/var/www/applications/ mypackage2/root/var/www/applications/kingdom/ mypackage2/root/var/www/applications/kingdom/cache/ mypackage2/tpkg.yml ck3.np.dc1.eharmony.com<http://ck3.np.dc1.eharmony.com> $ cat mypackage2/tpkg.yml name: kingdom version: 0.2011.8.3.2-1 maintainer: ian...@me...<mailto:ian...@me...> description: Kingdom build 0.2011.8.3.2-1 files: file_defaults: posix: owner: ddao group: roleusers perms: 0755 files: - path: /var/www/applications/kingdom/cache posix: owner: apache group: apache perms: 0777 ck3.np.dc1.eharmony.com<http://ck3.np.dc1.eharmony.com> $ tpkg -m mypackage2 Package is ./kingdom-0.2011.8.3.2-1.tpkg ck3.np.dc1.eharmony.com<http://ck3.np.dc1.eharmony.com> $ tpkg -i kingdom-0.2011.8.3.2-1.tpkg Executing with sudo The following packages will be installed: kingdom-0.2011.8.3.2-1.tpkg Confirm? [Y/n] ck3.np.dc1.eharmony.com<http://ck3.np.dc1.eharmony.com> $ ls -al /var/www/applications/kingdom/ total 12 drwxr-xr-x 3 ddao roleusers 4096 Aug 8 16:38 . drwxr-xr-x 4 ddao roleusers 4096 Aug 8 16:38 .. drwxrwxrwx 2 apache apache 4096 Aug 8 16:38 cache As you can see, the directory shows up as 0777 and is owned by apache. My guess is that there are other places where you might be touching that directory. Maybe in postinstall? It would help us troubleshoot this problem if you can create/attach a simple package (not just the yml file). -Darren On Mon, Aug 8, 2011 at 3:52 PM, Ian Young <Ian...@me...<mailto:Ian...@me...>> wrote: I installed it using the -debug option and I can see the permission metadata in the output. Once the installation is complete, however, the files/directories have the default attributes set. From: Ian Young [mailto:Ian...@me...<mailto:Ian...@me...>] Sent: Monday, August 08, 2011 2:38 PM To: tpk...@li...<mailto:tpk...@li...> Subject: [tpkg-users] directory permissions not persisting We have a tpkg.yml file that is supposed to change the ownership and permissions of some directories but they only retain the default attributes. I created a very simple test package with a few files and a directory and the yml file successfully changed the owner and group of the directory to apache, so there appears to be something wrong with the production package's configuration. I've attached the two yml files for comparison. ------------------------------------------------------------------------------ uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev _______________________________________________ tpkg-users mailing list tpk...@li...<mailto:tpk...@li...> https://lists.sourceforge.net/lists/listinfo/tpkg-users |
From: Ian Y. <Ian...@me...> - 2011-08-10 01:24:11
|
I tried creating a postinstall script to run chown apache on 3 directories but that didn't have any effect. I put it at the same level as the tpkg.yml file and gave it execute permission. After installation the directories were still owned by the user specified in the tpkg.yml file. Could there be anything that runs after the postinstall script? From: Ian Young [mailto:Ian...@me...] Sent: Monday, August 08, 2011 5:36 PM To: tpk...@li... Subject: Re: [tpkg-users] directory permissions not persisting The simple packages I create work as expected; it's the actual package to be used for production that has issues and, unfortunately, that can't be disseminated. There is no postinstall directory for this package. I modified the file_defaults in the yml file to see if it was respecting those settings. I changed owner to root and perms to 0650. Everything ended up owned by root, however, the 0650 permissions were only applied to files, not directories. Directory permissions were set to 0755. From: Darren Dao [mailto:dar...@gm...] Sent: Monday, August 08, 2011 5:01 PM To: Ian Young Cc: tpk...@li... Subject: Re: [tpkg-users] directory permissions not persisting I can't reproduce the problem using the yml files you provided. I used the tpkg-prod.yml file you attached and create a test package from it (see attachment). Here's my output ck3.np.dc1.eharmony.com<http://ck3.np.dc1.eharmony.com> $ tar xvf mypackage2.tar mypackage2/ mypackage2/root/ mypackage2/root/var/ mypackage2/root/var/www/ mypackage2/root/var/www/applications/ mypackage2/root/var/www/applications/kingdom/ mypackage2/root/var/www/applications/kingdom/cache/ mypackage2/tpkg.yml ck3.np.dc1.eharmony.com<http://ck3.np.dc1.eharmony.com> $ cat mypackage2/tpkg.yml name: kingdom version: 0.2011.8.3.2-1 maintainer: ian...@me...<mailto:ian...@me...> description: Kingdom build 0.2011.8.3.2-1 files: file_defaults: posix: owner: ddao group: roleusers perms: 0755 files: - path: /var/www/applications/kingdom/cache posix: owner: apache group: apache perms: 0777 ck3.np.dc1.eharmony.com<http://ck3.np.dc1.eharmony.com> $ tpkg -m mypackage2 Package is ./kingdom-0.2011.8.3.2-1.tpkg ck3.np.dc1.eharmony.com<http://ck3.np.dc1.eharmony.com> $ tpkg -i kingdom-0.2011.8.3.2-1.tpkg Executing with sudo The following packages will be installed: kingdom-0.2011.8.3.2-1.tpkg Confirm? [Y/n] ck3.np.dc1.eharmony.com<http://ck3.np.dc1.eharmony.com> $ ls -al /var/www/applications/kingdom/ total 12 drwxr-xr-x 3 ddao roleusers 4096 Aug 8 16:38 . drwxr-xr-x 4 ddao roleusers 4096 Aug 8 16:38 .. drwxrwxrwx 2 apache apache 4096 Aug 8 16:38 cache As you can see, the directory shows up as 0777 and is owned by apache. My guess is that there are other places where you might be touching that directory. Maybe in postinstall? It would help us troubleshoot this problem if you can create/attach a simple package (not just the yml file). -Darren On Mon, Aug 8, 2011 at 3:52 PM, Ian Young <Ian...@me...<mailto:Ian...@me...>> wrote: I installed it using the -debug option and I can see the permission metadata in the output. Once the installation is complete, however, the files/directories have the default attributes set. From: Ian Young [mailto:Ian...@me...<mailto:Ian...@me...>] Sent: Monday, August 08, 2011 2:38 PM To: tpk...@li...<mailto:tpk...@li...> Subject: [tpkg-users] directory permissions not persisting We have a tpkg.yml file that is supposed to change the ownership and permissions of some directories but they only retain the default attributes. I created a very simple test package with a few files and a directory and the yml file successfully changed the owner and group of the directory to apache, so there appears to be something wrong with the production package's configuration. I've attached the two yml files for comparison. ------------------------------------------------------------------------------ uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev _______________________________________________ tpkg-users mailing list tpk...@li...<mailto:tpk...@li...> https://lists.sourceforge.net/lists/listinfo/tpkg-users |
From: Ian Y. <Ian...@me...> - 2011-08-09 00:36:02
|
The simple packages I create work as expected; it's the actual package to be used for production that has issues and, unfortunately, that can't be disseminated. There is no postinstall directory for this package. I modified the file_defaults in the yml file to see if it was respecting those settings. I changed owner to root and perms to 0650. Everything ended up owned by root, however, the 0650 permissions were only applied to files, not directories. Directory permissions were set to 0755. From: Darren Dao [mailto:dar...@gm...] Sent: Monday, August 08, 2011 5:01 PM To: Ian Young Cc: tpk...@li... Subject: Re: [tpkg-users] directory permissions not persisting I can't reproduce the problem using the yml files you provided. I used the tpkg-prod.yml file you attached and create a test package from it (see attachment). Here's my output ck3.np.dc1.eharmony.com<http://ck3.np.dc1.eharmony.com> $ tar xvf mypackage2.tar mypackage2/ mypackage2/root/ mypackage2/root/var/ mypackage2/root/var/www/ mypackage2/root/var/www/applications/ mypackage2/root/var/www/applications/kingdom/ mypackage2/root/var/www/applications/kingdom/cache/ mypackage2/tpkg.yml ck3.np.dc1.eharmony.com<http://ck3.np.dc1.eharmony.com> $ cat mypackage2/tpkg.yml name: kingdom version: 0.2011.8.3.2-1 maintainer: ian...@me...<mailto:ian...@me...> description: Kingdom build 0.2011.8.3.2-1 files: file_defaults: posix: owner: ddao group: roleusers perms: 0755 files: - path: /var/www/applications/kingdom/cache posix: owner: apache group: apache perms: 0777 ck3.np.dc1.eharmony.com<http://ck3.np.dc1.eharmony.com> $ tpkg -m mypackage2 Package is ./kingdom-0.2011.8.3.2-1.tpkg ck3.np.dc1.eharmony.com<http://ck3.np.dc1.eharmony.com> $ tpkg -i kingdom-0.2011.8.3.2-1.tpkg Executing with sudo The following packages will be installed: kingdom-0.2011.8.3.2-1.tpkg Confirm? [Y/n] ck3.np.dc1.eharmony.com<http://ck3.np.dc1.eharmony.com> $ ls -al /var/www/applications/kingdom/ total 12 drwxr-xr-x 3 ddao roleusers 4096 Aug 8 16:38 . drwxr-xr-x 4 ddao roleusers 4096 Aug 8 16:38 .. drwxrwxrwx 2 apache apache 4096 Aug 8 16:38 cache As you can see, the directory shows up as 0777 and is owned by apache. My guess is that there are other places where you might be touching that directory. Maybe in postinstall? It would help us troubleshoot this problem if you can create/attach a simple package (not just the yml file). -Darren On Mon, Aug 8, 2011 at 3:52 PM, Ian Young <Ian...@me...<mailto:Ian...@me...>> wrote: I installed it using the -debug option and I can see the permission metadata in the output. Once the installation is complete, however, the files/directories have the default attributes set. From: Ian Young [mailto:Ian...@me...<mailto:Ian...@me...>] Sent: Monday, August 08, 2011 2:38 PM To: tpk...@li...<mailto:tpk...@li...> Subject: [tpkg-users] directory permissions not persisting We have a tpkg.yml file that is supposed to change the ownership and permissions of some directories but they only retain the default attributes. I created a very simple test package with a few files and a directory and the yml file successfully changed the owner and group of the directory to apache, so there appears to be something wrong with the production package's configuration. I've attached the two yml files for comparison. ------------------------------------------------------------------------------ uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev _______________________________________________ tpkg-users mailing list tpk...@li...<mailto:tpk...@li...> https://lists.sourceforge.net/lists/listinfo/tpkg-users |
From: Ian Y. <Ian...@me...> - 2011-08-08 22:52:51
|
I installed it using the -debug option and I can see the permission metadata in the output. Once the installation is complete, however, the files/directories have the default attributes set. From: Ian Young [mailto:Ian...@me...] Sent: Monday, August 08, 2011 2:38 PM To: tpk...@li... Subject: [tpkg-users] directory permissions not persisting We have a tpkg.yml file that is supposed to change the ownership and permissions of some directories but they only retain the default attributes. I created a very simple test package with a few files and a directory and the yml file successfully changed the owner and group of the directory to apache, so there appears to be something wrong with the production package's configuration. I've attached the two yml files for comparison. |
From: Jason H. <jh...@ap...> - 2011-04-21 22:01:41
|
Whoops, cut-n-paste error left a bit out of the release announcement: On Apr 21, 2011, at 1:56 PM, Jason Heiss wrote: > Bug fixes: > > - The Solaris package for installing tpkg now ensures that the modified /etc/profile has the proper permissions. Note that these permissions are set in the postremove script of the Solaris package, so an upgrade from a previous version of tpkg to 2.2.4 will still leave /etc/profile with the wrong permissions because they'll be set by the postremove in that old version. Removing and reinstalling 2.2.4, or on the next upgrade beyond 2.2.4, or a manual repair will get the permissions set properly right now. Jason |
From: Jason H. <jh...@ap...> - 2011-04-21 20:56:46
|
Enhancements: - Expand --force option to cover ignoring failures related to running externals. Failures related to bad externals can leave users in a situation where an old package can't be removed or upgraded. Users need a way to force their way out of that situation. - The profile.d file is now installed as tpkg.sh instead of tpkg_profile.sh to match the names of the other files typically found in the profile.d directory. - The profile.d file now adds /opt/tpkg/man or equivalent to MANPATH. - Add an etch externals script for triggering the installation of authorized_keys for a user. (The etch externals are not used by default.) - tpkg will now warn the user about non-executable init scripts, as otherwise that can lead to difficult to diagnose failures. (Other scripts run by tpkg such as preinstall and postinstall scripts already had similar checks and warnings.) Bug fixes: - The Solaris package for installing tpkg now ensures that the modified /etc/profile. |
From: Jason H. <jh...@ap...> - 2011-03-09 18:50:22
|
I'm glad you are finding tpkg useful. I'll be curious to hear how the integration with Portage goes. Jason On Mar 8, 2011, at 1:19 AM, Eduardo Tongson wrote: > Hey guys, > > tpkg is brilliant! If you're aware of the Ruby,Rubygems situation [1] > with various Linux distributions you will certainly appreciate what > tpkg does. The best thing is it can be used with any package. > > About creating tpkgs, I'm using Gentoo which use Portage (based on BSD > Ports). I believe it will be pretty easy to hook up the 'tpkg --make' > step to Portage' building process. > > I'll let you guys know how it goes. > Cheers! > > [1] https://bugs.launchpad.net/ubuntu/+source/ruby-defaults/+bug/634703 |
From: Eduardo T. <pro...@gm...> - 2011-03-08 09:19:32
|
Hey guys, tpkg is brilliant! If you're aware of the Ruby,Rubygems situation [1] with various Linux distributions you will certainly appreciate what tpkg does. The best thing is it can be used with any package. About creating tpkgs, I'm using Gentoo which use Portage (based on BSD Ports). I believe it will be pretty easy to hook up the 'tpkg --make' step to Portage' building process. I'll let you guys know how it goes. Cheers! [1] https://bugs.launchpad.net/ubuntu/+source/ruby-defaults/+bug/634703 |
From: Jason H. <jh...@ap...> - 2011-02-21 04:35:35
|
Bug fixes and enhancements: When installing a package and applying permissions to files attempt to use lchown/lchmod on symlinks. Previously permissions on symlinks were ignored. Not all systems support lchown/lchmod, on those systems this process will be skipped. Silence some harmless warnings from the library used to validate the syntax of the tpkg.yml file when making a package. Fix an issue in the client Rakefile introduced in the last release (2.2.2) that led to client packages with an invalid directory structure. The package_toplevel_directory now only reads the necessary first few blocks of the package rather than reading the whole package. That change should speed up operations involving larger packages. Minor API changes: - Metadata#write no longer takes a retain_format argument. No code existed to do anything with that argument, nor were any callers within the tpkg code base passing a value to retain_format. - Metadata#add_tpkg_version no longer rescues Errno::EACCES. Callers will need to rescue it if desired. - Metadata#get_native_deps now always returns an array. Previously it would sometime (but not always) return nil instead of an empty array if there were no native dependencies. That behavior was more-or-less documented and intended, so this qualifies as an API change rather than a bug fix. - Metadata#initialize now takes an additional parameter, the path to the metadata file. Previously this had to be set via an accessor call after instantiating an instance of Metadata. (For those on the tpkg-devel list I accidentally sent this to tpkg-devel first. Resending to tpkg-users.) |
From: Jason H. <jh...@ap...> - 2011-02-15 06:43:40
|
This release fixes a number of warnings that were seen when running tpkg under ruby 1.9. Running under 1.9 should now be warning-free. This release also fixes several issues associated with setting file permissions when installing packages containing symlinks. Jason |
From: Kenneth W. <hap...@gm...> - 2011-01-11 19:00:53
|
Fantastic, thanks jason! An idea for a future release; can we get something like etch's nodes.xml and nodegroups.xml so i can do something like tpkg --group=webservers, instead of manually specifying hosts, or is there something equivalent built in? Thanks! On Jan 10, 2011 8:51 PM, "Jason Heiss" <jh...@ap...> wrote: > I finally remembered to fix this in the 2.2.0 release. > > Jason > > On Aug 27, 2010, at 11:32 AM, Kenneth Williams wrote: > >> fyi, >> tpkg server seems to be dependent on some nventory libraries, but I don't see that mentioned in the docs anywhere. Maybe I missed it though... >> >> in tpkg/server/lib/tasks/tpkg.rake >> >> This causes rake db:migrate to fail. Two solutions... copying over the nventory files, or commenting it out... >> >> 4c4 >> < require 'nventory' >> --- >> > #require 'nventory' >> 16,23c16,23 >> < def get_tpkg_servers_for_environment(environment) >> < nvclient = NVentory::Client.new >> < servers = nvclient.get_expanded_nodegroup("tpkg_#{environment}") >> < if servers.empty? >> < abort "No servers found for environment '#{environment}'" >> < end >> < servers >> < end >> --- >> > #def get_tpkg_servers_for_environment(environment) >> > # nvclient = NVentory::Client.new >> > # servers = nvclient.get_expanded_nodegroup("tpkg_#{environment}") >> > # if servers.empty? >> > # abort "No servers found for environment '#{environment}'" >> > # end >> > # servers >> > #end >> >> I went for the later since I don't really want to auto populate those fields anyway. Also, there does not seem to be a default username and password for the reporting server ui -- This might be an irritating road block for new users. >> >> Thanks! >> ------------------------------------------------------------------------------ >> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program >> Be part of this innovative community and reach millions of netbook users >> worldwide. Take advantage of special opportunities to increase revenue and >> speed time-to-market. Join now, and jumpstart your future. >> http://p.sf.net/sfu/intel-atom-d2d_______________________________________________ >> tpkg-users mailing list >> tpk...@li... >> https://lists.sourceforge.net/lists/listinfo/tpkg-users > |
From: Jason H. <jh...@ap...> - 2011-01-11 04:51:35
|
I finally remembered to fix this in the 2.2.0 release. Jason On Aug 27, 2010, at 11:32 AM, Kenneth Williams wrote: > fyi, > tpkg server seems to be dependent on some nventory libraries, but I don't see that mentioned in the docs anywhere. Maybe I missed it though... > > in tpkg/server/lib/tasks/tpkg.rake > > This causes rake db:migrate to fail. Two solutions... copying over the nventory files, or commenting it out... > > 4c4 > < require 'nventory' > --- > > #require 'nventory' > 16,23c16,23 > < def get_tpkg_servers_for_environment(environment) > < nvclient = NVentory::Client.new > < servers = nvclient.get_expanded_nodegroup("tpkg_#{environment}") > < if servers.empty? > < abort "No servers found for environment '#{environment}'" > < end > < servers > < end > --- > > #def get_tpkg_servers_for_environment(environment) > > # nvclient = NVentory::Client.new > > # servers = nvclient.get_expanded_nodegroup("tpkg_#{environment}") > > # if servers.empty? > > # abort "No servers found for environment '#{environment}'" > > # end > > # servers > > #end > > I went for the later since I don't really want to auto populate those fields anyway. Also, there does not seem to be a default username and password for the reporting server ui -- This might be an irritating road block for new users. > > Thanks! > ------------------------------------------------------------------------------ > Sell apps to millions through the Intel(R) Atom(Tm) Developer Program > Be part of this innovative community and reach millions of netbook users > worldwide. Take advantage of special opportunities to increase revenue and > speed time-to-market. Join now, and jumpstart your future. > http://p.sf.net/sfu/intel-atom-d2d_______________________________________________ > tpkg-users mailing list > tpk...@li... > https://lists.sourceforge.net/lists/listinfo/tpkg-users |
From: Jason H. <jh...@ap...> - 2011-01-11 04:51:28
|
Add --base and --test-root options to the tpkg client. Preserve base directory setting when running tpkg via sudo or remotely by using the --base option rather than "env TPKG_HOME". This ensures that tpkg is still the command being executed, rather than env. This is important if sudo rules only allow the user to run tpkg. Add man pages for cpan2tpkg and gem2tpkg. |
From: Jason H. <jh...@ap...> - 2011-01-04 07:15:06
|
Minor bugfix release: * Fix handling of --use-ssh-key without an argument (broken in 2.1.0). * Fix file path in tpkgpkg rake task. |
From: Jason H. <jh...@ap...> - 2010-12-17 19:16:03
|
User visible changes: ticket:23 Add "status" as a standard init script option ticket:25 Preserve TPKG_HOME when deploying to remote systems. Warn instead of raising an exception if there is no init or crontab support for the platform. These seem like valid cases where proceeding with reduced functionality is better than failing. API changes: In class Tpkg change CONFIGDIR to DEFAULT_CONFIGDIR, and compute @configdir in initialize method using a similar algorithm as for @base. This allows the test suite to use a private config directory and not be affected by any files in the system config directory. Change gethttp method from class to instance method so that it can utilize @configdir. Make the :base option to initialize actually optional, setting it to DEFAULT_BASE if it is not specified. The tpkg executable is essentially doing that as well, but other users of the library would benefit from the same logic. |