[arch-dev-public] Moving the DB scripts
Hey all, I'm going to move the new db scripts live. In an hour or so. I still need to generalize Pierre's testing2core script and commit it, then I will push them live. Once I do that, it is going to break the website updates for a short period - until Eliott can get to the web changes (we haven't been able to coordinate properly, so rather than wasting time, I'm doing this move now). So, if you guys could hold off doing repo related activities in about an hour or so, that'd be great. One fun addition: /arch/db-remove No more need for package files to remove a package. Syntax is: db-remove pkgname repo arch Cheers, Aaron
On Tue, 20 May 2008, Aaron Griffin wrote:
Hey all, I'm going to move the new db scripts live. In an hour or so. I still need to generalize Pierre's testing2core script and commit it, then I will push them live.
Once I do that, it is going to break the website updates for a short period - until Eliott can get to the web changes (we haven't been able to coordinate properly, so rather than wasting time, I'm doing this move now).
So, if you guys could hold off doing repo related activities in about an hour or so, that'd be great.
One fun addition: /arch/db-remove No more need for package files to remove a package. Syntax is: db-remove pkgname repo arch
Cheers, Aaron
Status update: Aaron just contacted me via Jabber. Due to time constraint as it's becoming late, the move will happen tomorrow. Eric -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
On Tue, May 20, 2008 at 11:36 PM, Eric Belanger <belanger@astro.umontreal.ca> wrote:
On Tue, 20 May 2008, Aaron Griffin wrote:
Hey all, I'm going to move the new db scripts live. In an hour or so. I still need to generalize Pierre's testing2core script and commit it, then I will push them live.
Once I do that, it is going to break the website updates for a short period - until Eliott can get to the web changes (we haven't been able to coordinate properly, so rather than wasting time, I'm doing this move now).
So, if you guys could hold off doing repo related activities in about an hour or so, that'd be great.
One fun addition: /arch/db-remove No more need for package files to remove a package. Syntax is: db-remove pkgname repo arch
Cheers, Aaron
Status update:
Aaron just contacted me via Jabber. Due to time constraint as it's becoming late, the move will happen tomorrow.
Thanks Eric. Additionally, I added 'db-move' which is a generalization of Pierre's testing2extra script. db-move, testing2extra, and testing2core are all in /arch-new if you want to test them. As you can see from the commits ML, I moved openssh this way (I didn't know that was still in testing, my fault there)
On Tue, May 20, 2008 at 11:53 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Tue, May 20, 2008 at 11:36 PM, Eric Belanger <belanger@astro.umontreal.ca> wrote:
On Tue, 20 May 2008, Aaron Griffin wrote:
Hey all, I'm going to move the new db scripts live. In an hour or so. I still need to generalize Pierre's testing2core script and commit it, then I will push them live.
Once I do that, it is going to break the website updates for a short period - until Eliott can get to the web changes (we haven't been able to coordinate properly, so rather than wasting time, I'm doing this move now).
So, if you guys could hold off doing repo related activities in about an hour or so, that'd be great.
One fun addition: /arch/db-remove No more need for package files to remove a package. Syntax is: db-remove pkgname repo arch
Cheers, Aaron
Status update:
Aaron just contacted me via Jabber. Due to time constraint as it's becoming late, the move will happen tomorrow.
Thanks Eric. Additionally, I added 'db-move' which is a generalization of Pierre's testing2extra script. db-move, testing2extra, and testing2core are all in /arch-new if you want to test them.
As you can see from the commits ML, I moved openssh this way (I didn't know that was still in testing, my fault there)
Ok, I'm going to make this move right now. First, I am going to regen all of the DB files with repo-add, then I will move the /arch-new dir to /arch, and we should be gold. Cheers
On Wed, May 21, 2008 at 1:07 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Tue, May 20, 2008 at 11:53 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Tue, May 20, 2008 at 11:36 PM, Eric Belanger <belanger@astro.umontreal.ca> wrote:
On Tue, 20 May 2008, Aaron Griffin wrote:
Hey all, I'm going to move the new db scripts live. In an hour or so. I still need to generalize Pierre's testing2core script and commit it, then I will push them live.
Once I do that, it is going to break the website updates for a short period - until Eliott can get to the web changes (we haven't been able to coordinate properly, so rather than wasting time, I'm doing this move now).
So, if you guys could hold off doing repo related activities in about an hour or so, that'd be great.
One fun addition: /arch/db-remove No more need for package files to remove a package. Syntax is: db-remove pkgname repo arch
Cheers, Aaron
Status update:
Aaron just contacted me via Jabber. Due to time constraint as it's becoming late, the move will happen tomorrow.
Thanks Eric. Additionally, I added 'db-move' which is a generalization of Pierre's testing2extra script. db-move, testing2extra, and testing2core are all in /arch-new if you want to test them.
As you can see from the commits ML, I moved openssh this way (I didn't know that was still in testing, my fault there)
Ok, I'm going to make this move right now. First, I am going to regen all of the DB files with repo-add, then I will move the /arch-new dir to /arch, and we should be gold.
Cheers
One thing to note: I decided to kill off the staging/*64 dirs - we have the arch in the package name, there is no reason we need different dirs. The current scripts take care of this by copying ${repo}64 to ${repo} before doing anything, and there is a change in devtools to upload to only one staging dir. We just need to make a new devtools release.
On Wed, May 21, 2008 at 1:22 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Wed, May 21, 2008 at 1:07 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Tue, May 20, 2008 at 11:53 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Tue, May 20, 2008 at 11:36 PM, Eric Belanger <belanger@astro.umontreal.ca> wrote:
On Tue, 20 May 2008, Aaron Griffin wrote:
Hey all, I'm going to move the new db scripts live. In an hour or so. I still need to generalize Pierre's testing2core script and commit it, then I will push them live.
Once I do that, it is going to break the website updates for a short period - until Eliott can get to the web changes (we haven't been able to coordinate properly, so rather than wasting time, I'm doing this move now).
So, if you guys could hold off doing repo related activities in about an hour or so, that'd be great.
One fun addition: /arch/db-remove No more need for package files to remove a package. Syntax is: db-remove pkgname repo arch
Cheers, Aaron
Status update:
Aaron just contacted me via Jabber. Due to time constraint as it's becoming late, the move will happen tomorrow.
Thanks Eric. Additionally, I added 'db-move' which is a generalization of Pierre's testing2extra script. db-move, testing2extra, and testing2core are all in /arch-new if you want to test them.
As you can see from the commits ML, I moved openssh this way (I didn't know that was still in testing, my fault there)
Ok, I'm going to make this move right now. First, I am going to regen all of the DB files with repo-add, then I will move the /arch-new dir to /arch, and we should be gold.
Cheers
One thing to note: I decided to kill off the staging/*64 dirs - we have the arch in the package name, there is no reason we need different dirs. The current scripts take care of this by copying ${repo}64 to ${repo} before doing anything, and there is a change in devtools to upload to only one staging dir. We just need to make a new devtools release.
Move complete, all DB files replaces with repo-add generated DBs (yes!) New scripts are in /arch/. Please let me know if there is any error or anything like that - I don't think most people really tested them that well 8) Now to configure some cleanup cron jobs
On Wed, 21 May 2008, Aaron Griffin wrote:
Move complete, all DB files replaces with repo-add generated DBs (yes!)
New scripts are in /arch/. Please let me know if there is any error or anything like that - I don't think most people really tested them that well 8)
Now to configure some cleanup cron jobs
I just updated some packages and it looks okay according to the status of things from what I know: - didn't show up on website yet - script reports nothing to delete, this will be taken care of by the cronjobs i think -T
On Wed, May 21, 2008 at 4:55 PM, Tobias Kieslich <tobias@justdreams.de> wrote:
On Wed, 21 May 2008, Aaron Griffin wrote:
Move complete, all DB files replaces with repo-add generated DBs (yes!)
New scripts are in /arch/. Please let me know if there is any error or anything like that - I don't think most people really tested them that well 8)
Now to configure some cleanup cron jobs
I just updated some packages and it looks okay according to the status of things from what I know:
- didn't show up on website yet
This won't happen until eliott updates the web interface.
On Wed, May 21, 2008 at 4:57 PM, Travis Willard <travis@archlinux.org> wrote:
On Wed, May 21, 2008 at 4:55 PM, Tobias Kieslich <tobias@justdreams.de> wrote:
On Wed, 21 May 2008, Aaron Griffin wrote:
Move complete, all DB files replaces with repo-add generated DBs (yes!)
New scripts are in /arch/. Please let me know if there is any error or anything like that - I don't think most people really tested them that well 8)
Now to configure some cleanup cron jobs
I just updated some packages and it looks okay according to the status of things from what I know:
- didn't show up on website yet
This won't happen until eliott updates the web interface.
Er... webSITE. Until the webSITE is updated... blarghl.
On Wed, 21 May 2008, Travis Willard wrote:
Er... webSITE. Until the webSITE is updated... blarghl.
Yeah, sorry. I didn't mention that but figured that. Good job guys. -T
On Wed, May 21, 2008 at 3:55 PM, Tobias Kieslich <tobias@justdreams.de> wrote:
On Wed, 21 May 2008, Aaron Griffin wrote:
Move complete, all DB files replaces with repo-add generated DBs (yes!)
New scripts are in /arch/. Please let me know if there is any error or anything like that - I don't think most people really tested them that well 8)
Now to configure some cleanup cron jobs
I just updated some packages and it looks okay according to the status of things from what I know:
- didn't show up on website yet - script reports nothing to delete, this will be taken care of by the cronjobs i think
Yeah, the deleted stuff will be taken care of automatically, and I'm going to have it spit off emails to the ML when it actually does things. It will also report missing packages, and packages that aren't in the DB at all. Example output (I just ran it, so it will be fairly clean): Scan complete for extra (i686) at /home/ftp/extra/os/i686/ The following files are out of date They will be moved to /home/package-cleanup blender-2.45-1-i686.pkg.tar.gz bogofilter-1.1.6-1-i686.pkg.tar.gz dcraw-1.399-1-i686.pkg.tar.gz mutt-1.5.17-4-i686.pkg.tar.gz qgit-1.5.7-2-i686.pkg.tar.gz rox-2.7.1-1-i686.pkg.tar.gz vlc-0.8.6g-1-i686.pkg.tar.gz
Thanks Aaron, that list looks entirely perfect to me :P -T On Wed, 21 May 2008, Aaron Griffin wrote:
Example output (I just ran it, so it will be fairly clean):
Scan complete for extra (i686) at /home/ftp/extra/os/i686/ The following files are out of date They will be moved to /home/package-cleanup blender-2.45-1-i686.pkg.tar.gz bogofilter-1.1.6-1-i686.pkg.tar.gz dcraw-1.399-1-i686.pkg.tar.gz mutt-1.5.17-4-i686.pkg.tar.gz qgit-1.5.7-2-i686.pkg.tar.gz rox-2.7.1-1-i686.pkg.tar.gz vlc-0.8.6g-1-i686.pkg.tar.gz
Am Mittwoch, 21. Mai 2008 20:43:57 schrieb Aaron Griffin:
New scripts are in /arch/. Please let me know if there is any error or anything like that
There is something strange about db-remove: echo "usage: $(basename $0) <pkgname> <arch> <reponame>" vs. packagename="$1" reponame="$2" arch="$3" -- http://www.archlinux.de
On Thu, May 22, 2008 at 5:28 AM, Pierre Schmitz <pierre@archlinux.de> wrote:
Am Mittwoch, 21. Mai 2008 20:43:57 schrieb Aaron Griffin:
New scripts are in /arch/. Please let me know if there is any error or anything like that
There is something strange about db-remove:
echo "usage: $(basename $0) <pkgname> <arch> <reponame>"
vs.
packagename="$1" reponame="$2" arch="$3"
Whoops, my fault - usage text is wrong. I tried to put the arch at the end with all those scripts
On Tue, 20 May 2008, Aaron Griffin wrote:
On Tue, May 20, 2008 at 11:36 PM, Eric Belanger <belanger@astro.umontreal.ca> wrote:
On Tue, 20 May 2008, Aaron Griffin wrote:
Hey all, I'm going to move the new db scripts live. In an hour or so. I still need to generalize Pierre's testing2core script and commit it, then I will push them live.
Once I do that, it is going to break the website updates for a short period - until Eliott can get to the web changes (we haven't been able to coordinate properly, so rather than wasting time, I'm doing this move now).
So, if you guys could hold off doing repo related activities in about an hour or so, that'd be great.
One fun addition: /arch/db-remove No more need for package files to remove a package. Syntax is: db-remove pkgname repo arch
Cheers, Aaron
Status update:
Aaron just contacted me via Jabber. Due to time constraint as it's becoming late, the move will happen tomorrow.
Thanks Eric. Additionally, I added 'db-move' which is a generalization of Pierre's testing2extra script. db-move, testing2extra, and testing2core are all in /arch-new if you want to test them.
I tried to use testing2core but it didn't work. It's the first time I use a script to do that so I might be doing it wrong. First, I did the usual archrelease stuff locally. Then I logged on gerolde and: $ /arch/testing2core licenses bzip2 ==> Moving package 'licenses' Checked out revision 1848. Error: licenses is not in repo testing ==> Moving package 'bzip2' Checked out revision 1848. Error: bzip2 is not in repo testing Did I had to copy the packages in the staging directories before? Or is it something else? I eventually did it manually and that worked. Also, I noticed that the new db script no longer removes the files in the staging/${repo}64/* directories. I know it'll be a moot issues when the devtools package will be updated but, instead of copying the packages to staging/${repo}/*, can't it just move them there? Of course, if devtools is planned to be updated soon then you can ignore this request. Eric -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
On Thu, May 22, 2008 at 10:30 AM, Eric Belanger <belanger@astro.umontreal.ca> wrote:
On Tue, 20 May 2008, Aaron Griffin wrote:
On Tue, May 20, 2008 at 11:36 PM, Eric Belanger <belanger@astro.umontreal.ca> wrote:
On Tue, 20 May 2008, Aaron Griffin wrote:
Hey all, I'm going to move the new db scripts live. In an hour or so. I still need to generalize Pierre's testing2core script and commit it, then I will push them live.
Once I do that, it is going to break the website updates for a short period - until Eliott can get to the web changes (we haven't been able to coordinate properly, so rather than wasting time, I'm doing this move now).
So, if you guys could hold off doing repo related activities in about an hour or so, that'd be great.
One fun addition: /arch/db-remove No more need for package files to remove a package. Syntax is: db-remove pkgname repo arch
Cheers, Aaron
Status update:
Aaron just contacted me via Jabber. Due to time constraint as it's becoming late, the move will happen tomorrow.
Thanks Eric. Additionally, I added 'db-move' which is a generalization of Pierre's testing2extra script. db-move, testing2extra, and testing2core are all in /arch-new if you want to test them.
I tried to use testing2core but it didn't work. It's the first time I use a script to do that so I might be doing it wrong. First, I did the usual archrelease stuff locally. Then I logged on gerolde and:
$ /arch/testing2core licenses bzip2 ==> Moving package 'licenses' Checked out revision 1848. Error: licenses is not in repo testing ==> Moving package 'bzip2' Checked out revision 1848. Error: bzip2 is not in repo testing
Did I had to copy the packages in the staging directories before? Or is it something else? I eventually did it manually and that worked.
Ah, yeah - those scripts mean you don't have to do anything locally. If it's in testing, just connect to gerolde and run "testing2core" It's only one step.
Also, I noticed that the new db script no longer removes the files in the staging/${repo}64/* directories. I know it'll be a moot issues when the devtools package will be updated but, instead of copying the packages to staging/${repo}/*, can't it just move them there? Of course, if devtools is planned to be updated soon then you can ignore this request.
Ah yeah, I overlooked that. Right now I copy files from the *64 dirs to the non-suffixed ones. I guess I could 'mv' them to cover all the bases
On Thu, May 22, 2008 at 11:03 AM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Thu, May 22, 2008 at 10:30 AM, Eric Belanger <belanger@astro.umontreal.ca> wrote:
On Tue, 20 May 2008, Aaron Griffin wrote:
On Tue, May 20, 2008 at 11:36 PM, Eric Belanger <belanger@astro.umontreal.ca> wrote:
On Tue, 20 May 2008, Aaron Griffin wrote:
Hey all, I'm going to move the new db scripts live. In an hour or so. I still need to generalize Pierre's testing2core script and commit it, then I will push them live.
Once I do that, it is going to break the website updates for a short period - until Eliott can get to the web changes (we haven't been able to coordinate properly, so rather than wasting time, I'm doing this move now).
So, if you guys could hold off doing repo related activities in about an hour or so, that'd be great.
One fun addition: /arch/db-remove No more need for package files to remove a package. Syntax is: db-remove pkgname repo arch
Cheers, Aaron
Status update:
Aaron just contacted me via Jabber. Due to time constraint as it's becoming late, the move will happen tomorrow.
Thanks Eric. Additionally, I added 'db-move' which is a generalization of Pierre's testing2extra script. db-move, testing2extra, and testing2core are all in /arch-new if you want to test them.
I tried to use testing2core but it didn't work. It's the first time I use a script to do that so I might be doing it wrong. First, I did the usual archrelease stuff locally. Then I logged on gerolde and:
$ /arch/testing2core licenses bzip2 ==> Moving package 'licenses' Checked out revision 1848. Error: licenses is not in repo testing ==> Moving package 'bzip2' Checked out revision 1848. Error: bzip2 is not in repo testing
Did I had to copy the packages in the staging directories before? Or is it something else? I eventually did it manually and that worked.
Ah, yeah - those scripts mean you don't have to do anything locally. If it's in testing, just connect to gerolde and run "testing2core" It's only one step.
Also, I noticed that the new db script no longer removes the files in the staging/${repo}64/* directories. I know it'll be a moot issues when the devtools package will be updated but, instead of copying the packages to staging/${repo}/*, can't it just move them there? Of course, if devtools is planned to be updated soon then you can ignore this request.
Ah yeah, I overlooked that. Right now I copy files from the *64 dirs to the non-suffixed ones. I guess I could 'mv' them to cover all the bases
Updated the scripts: fixed db-remove usage output use 'mv' to transfer from staging64
On Thu, May 22, 2008 at 11:56 AM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Thu, May 22, 2008 at 11:03 AM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Thu, May 22, 2008 at 10:30 AM, Eric Belanger <belanger@astro.umontreal.ca> wrote:
On Tue, 20 May 2008, Aaron Griffin wrote:
On Tue, May 20, 2008 at 11:36 PM, Eric Belanger <belanger@astro.umontreal.ca> wrote:
On Tue, 20 May 2008, Aaron Griffin wrote:
Hey all, I'm going to move the new db scripts live. In an hour or so. I still need to generalize Pierre's testing2core script and commit it, then I will push them live.
Once I do that, it is going to break the website updates for a short period - until Eliott can get to the web changes (we haven't been able to coordinate properly, so rather than wasting time, I'm doing this move now).
So, if you guys could hold off doing repo related activities in about an hour or so, that'd be great.
One fun addition: /arch/db-remove No more need for package files to remove a package. Syntax is: db-remove pkgname repo arch
Cheers, Aaron
Status update:
Aaron just contacted me via Jabber. Due to time constraint as it's becoming late, the move will happen tomorrow.
Thanks Eric. Additionally, I added 'db-move' which is a generalization of Pierre's testing2extra script. db-move, testing2extra, and testing2core are all in /arch-new if you want to test them.
I tried to use testing2core but it didn't work. It's the first time I use a script to do that so I might be doing it wrong. First, I did the usual archrelease stuff locally. Then I logged on gerolde and:
$ /arch/testing2core licenses bzip2 ==> Moving package 'licenses' Checked out revision 1848. Error: licenses is not in repo testing ==> Moving package 'bzip2' Checked out revision 1848. Error: bzip2 is not in repo testing
Did I had to copy the packages in the staging directories before? Or is it something else? I eventually did it manually and that worked.
Ah, yeah - those scripts mean you don't have to do anything locally. If it's in testing, just connect to gerolde and run "testing2core" It's only one step.
Also, I noticed that the new db script no longer removes the files in the staging/${repo}64/* directories. I know it'll be a moot issues when the devtools package will be updated but, instead of copying the packages to staging/${repo}/*, can't it just move them there? Of course, if devtools is planned to be updated soon then you can ignore this request.
Ah yeah, I overlooked that. Right now I copy files from the *64 dirs to the non-suffixed ones. I guess I could 'mv' them to cover all the bases
Updated the scripts: fixed db-remove usage output use 'mv' to transfer from staging64
Updated "removing" and "move to another repo" here: http://wiki.archlinux.org/index.php/DeveloperWiki:HOWTO_Be_A_Packager Please take a look when you get a chance
On Thu, May 22, 2008 at 1:34 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Thu, May 22, 2008 at 11:56 AM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Thu, May 22, 2008 at 11:03 AM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Thu, May 22, 2008 at 10:30 AM, Eric Belanger <belanger@astro.umontreal.ca> wrote:
On Tue, 20 May 2008, Aaron Griffin wrote:
On Tue, May 20, 2008 at 11:36 PM, Eric Belanger <belanger@astro.umontreal.ca> wrote:
On Tue, 20 May 2008, Aaron Griffin wrote:
> Hey all, > I'm going to move the new db scripts live. In an hour or so. I still > need to generalize Pierre's testing2core script and commit it, then I > will push them live. > > Once I do that, it is going to break the website updates for a short > period - until Eliott can get to the web changes (we haven't been able > to coordinate properly, so rather than wasting time, I'm doing this > move now). > > So, if you guys could hold off doing repo related activities in about > an hour or so, that'd be great. > > One fun addition: /arch/db-remove > No more need for package files to remove a package. Syntax is: > db-remove pkgname repo arch > > Cheers, > Aaron >
Status update:
Aaron just contacted me via Jabber. Due to time constraint as it's becoming late, the move will happen tomorrow.
Thanks Eric. Additionally, I added 'db-move' which is a generalization of Pierre's testing2extra script. db-move, testing2extra, and testing2core are all in /arch-new if you want to test them.
I tried to use testing2core but it didn't work. It's the first time I use a script to do that so I might be doing it wrong. First, I did the usual archrelease stuff locally. Then I logged on gerolde and:
$ /arch/testing2core licenses bzip2 ==> Moving package 'licenses' Checked out revision 1848. Error: licenses is not in repo testing ==> Moving package 'bzip2' Checked out revision 1848. Error: bzip2 is not in repo testing
Did I had to copy the packages in the staging directories before? Or is it something else? I eventually did it manually and that worked.
Ah, yeah - those scripts mean you don't have to do anything locally. If it's in testing, just connect to gerolde and run "testing2core" It's only one step.
Also, I noticed that the new db script no longer removes the files in the staging/${repo}64/* directories. I know it'll be a moot issues when the devtools package will be updated but, instead of copying the packages to staging/${repo}/*, can't it just move them there? Of course, if devtools is planned to be updated soon then you can ignore this request.
Ah yeah, I overlooked that. Right now I copy files from the *64 dirs to the non-suffixed ones. I guess I could 'mv' them to cover all the bases
Updated the scripts: fixed db-remove usage output use 'mv' to transfer from staging64
Updated "removing" and "move to another repo" here: http://wiki.archlinux.org/index.php/DeveloperWiki:HOWTO_Be_A_Packager
Please take a look when you get a chance
Looks reasonable to me
On Thu, May 22, 2008 at 12:37 PM, Travis Willard <travis@archlinux.org> wrote:
On Thu, May 22, 2008 at 1:34 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Thu, May 22, 2008 at 11:56 AM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Thu, May 22, 2008 at 11:03 AM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Thu, May 22, 2008 at 10:30 AM, Eric Belanger <belanger@astro.umontreal.ca> wrote:
On Tue, 20 May 2008, Aaron Griffin wrote:
On Tue, May 20, 2008 at 11:36 PM, Eric Belanger <belanger@astro.umontreal.ca> wrote: > > On Tue, 20 May 2008, Aaron Griffin wrote: > >> Hey all, >> I'm going to move the new db scripts live. In an hour or so. I still >> need to generalize Pierre's testing2core script and commit it, then I >> will push them live. >> >> Once I do that, it is going to break the website updates for a short >> period - until Eliott can get to the web changes (we haven't been able >> to coordinate properly, so rather than wasting time, I'm doing this >> move now). >> >> So, if you guys could hold off doing repo related activities in about >> an hour or so, that'd be great. >> >> One fun addition: /arch/db-remove >> No more need for package files to remove a package. Syntax is: >> db-remove pkgname repo arch >> >> Cheers, >> Aaron >> > > > Status update: > > Aaron just contacted me via Jabber. Due to time constraint as it's > becoming > late, the move will happen tomorrow.
Thanks Eric. Additionally, I added 'db-move' which is a generalization of Pierre's testing2extra script. db-move, testing2extra, and testing2core are all in /arch-new if you want to test them.
I tried to use testing2core but it didn't work. It's the first time I use a script to do that so I might be doing it wrong. First, I did the usual archrelease stuff locally. Then I logged on gerolde and:
$ /arch/testing2core licenses bzip2 ==> Moving package 'licenses' Checked out revision 1848. Error: licenses is not in repo testing ==> Moving package 'bzip2' Checked out revision 1848. Error: bzip2 is not in repo testing
Did I had to copy the packages in the staging directories before? Or is it something else? I eventually did it manually and that worked.
Ah, yeah - those scripts mean you don't have to do anything locally. If it's in testing, just connect to gerolde and run "testing2core" It's only one step.
Also, I noticed that the new db script no longer removes the files in the staging/${repo}64/* directories. I know it'll be a moot issues when the devtools package will be updated but, instead of copying the packages to staging/${repo}/*, can't it just move them there? Of course, if devtools is planned to be updated soon then you can ignore this request.
Ah yeah, I overlooked that. Right now I copy files from the *64 dirs to the non-suffixed ones. I guess I could 'mv' them to cover all the bases
Updated the scripts: fixed db-remove usage output use 'mv' to transfer from staging64
Updated "removing" and "move to another repo" here: http://wiki.archlinux.org/index.php/DeveloperWiki:HOWTO_Be_A_Packager
Please take a look when you get a chance
Looks reasonable to me
Side note for SVN pros - I noticed Jan using db-move and each one is two commits. For you people more familiar with svn, could I do an "rm" and a "copy" in one commit?
On Thu, 2008-05-22 at 12:55 -0500, Aaron Griffin wrote:
Side note for SVN pros - I noticed Jan using db-move and each one is two commits. For you people more familiar with svn, could I do an "rm" and a "copy" in one commit?
Yes you can. Actually there's an svn move command which does the same action in one operation.
Am Donnerstag, 22. Mai 2008 21:06:07 schrieb Jan de Groot:
Yes you can. Actually there's an svn move command which does the same action in one operation.
Does it remove files from the traget dir which are not in the source dir? That's why I have used svn rm before in testing2extra. -- http://www.archlinux.de
On Thu, 2008-05-22 at 21:09 +0200, Pierre Schmitz wrote:
Am Donnerstag, 22. Mai 2008 21:06:07 schrieb Jan de Groot:
Yes you can. Actually there's an svn move command which does the same action in one operation.
Does it remove files from the traget dir which are not in the source dir? That's why I have used svn rm before in testing2extra.
No, svn move is just a simple add & delete command that adds the file as new file and removes the old filename. It doesn't merge directories.
On Thu, May 22, 2008 at 2:14 PM, Jan de Groot <jan@jgc.homeip.net> wrote:
On Thu, 2008-05-22 at 21:09 +0200, Pierre Schmitz wrote:
Am Donnerstag, 22. Mai 2008 21:06:07 schrieb Jan de Groot:
Yes you can. Actually there's an svn move command which does the same action in one operation.
Does it remove files from the traget dir which are not in the source dir? That's why I have used svn rm before in testing2extra.
No, svn move is just a simple add & delete command that adds the file as new file and removes the old filename. It doesn't merge directories.
Right, what I want is this: delete extra-i686/ move testing-i686/ extra-i686/ I assumed (because Pierre did it this way) that you need to commit the first 'rm' before the 'mv' will go through
On Thu, May 22, 2008 at 12:18 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Thu, May 22, 2008 at 2:14 PM, Jan de Groot <jan@jgc.homeip.net> wrote:
On Thu, 2008-05-22 at 21:09 +0200, Pierre Schmitz wrote:
Am Donnerstag, 22. Mai 2008 21:06:07 schrieb Jan de Groot:
Yes you can. Actually there's an svn move command which does the same action in one operation.
Does it remove files from the traget dir which are not in the source dir? That's why I have used svn rm before in testing2extra.
No, svn move is just a simple add & delete command that adds the file as new file and removes the old filename. It doesn't merge directories.
Right, what I want is this: delete extra-i686/ move testing-i686/ extra-i686/
I assumed (because Pierre did it this way) that you need to commit the first 'rm' before the 'mv' will go through
I'm telling you now that this is what you must do. There is no way to delete a dir and add it again in the same commit. I think it'l a limitation of the svn working copy implementation vs. a limitation of the repo format. Jason
On Thu, May 22, 2008 at 3:53 PM, Jason Chu <jason@archlinux.org> wrote:
On Thu, May 22, 2008 at 12:18 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Thu, May 22, 2008 at 2:14 PM, Jan de Groot <jan@jgc.homeip.net> wrote:
On Thu, 2008-05-22 at 21:09 +0200, Pierre Schmitz wrote:
Am Donnerstag, 22. Mai 2008 21:06:07 schrieb Jan de Groot:
Yes you can. Actually there's an svn move command which does the same action in one operation.
Does it remove files from the traget dir which are not in the source dir? That's why I have used svn rm before in testing2extra.
No, svn move is just a simple add & delete command that adds the file as new file and removes the old filename. It doesn't merge directories.
Right, what I want is this: delete extra-i686/ move testing-i686/ extra-i686/
I assumed (because Pierre did it this way) that you need to commit the first 'rm' before the 'mv' will go through
I'm telling you now that this is what you must do. There is no way to delete a dir and add it again in the same commit. I think it'l a limitation of the svn working copy implementation vs. a limitation of the repo format.
Jason
Boo! Ah well
On Thu, May 22, 2008 at 4:53 PM, Jason Chu <jason@archlinux.org> wrote:
On Thu, May 22, 2008 at 12:18 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Thu, May 22, 2008 at 2:14 PM, Jan de Groot <jan@jgc.homeip.net> wrote:
On Thu, 2008-05-22 at 21:09 +0200, Pierre Schmitz wrote:
Am Donnerstag, 22. Mai 2008 21:06:07 schrieb Jan de Groot:
Yes you can. Actually there's an svn move command which does the same action in one operation.
Does it remove files from the traget dir which are not in the source dir? That's why I have used svn rm before in testing2extra.
No, svn move is just a simple add & delete command that adds the file as new file and removes the old filename. It doesn't merge directories.
Right, what I want is this: delete extra-i686/ move testing-i686/ extra-i686/
I assumed (because Pierre did it this way) that you need to commit the first 'rm' before the 'mv' will go through
I'm telling you now that this is what you must do. There is no way to delete a dir and add it again in the same commit. I think it'l a limitation of the svn working copy implementation vs. a limitation of the repo format.
So... why delete the dir? Would something like this work? delete extra-i686/* move testing-i686/* extra-i686/ delete testing-i686
On Thu, May 22, 2008 at 4:23 PM, Travis Willard <travis@archlinux.org> wrote:
On Thu, May 22, 2008 at 4:53 PM, Jason Chu <jason@archlinux.org> wrote:
On Thu, May 22, 2008 at 12:18 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Thu, May 22, 2008 at 2:14 PM, Jan de Groot <jan@jgc.homeip.net> wrote:
On Thu, 2008-05-22 at 21:09 +0200, Pierre Schmitz wrote:
Am Donnerstag, 22. Mai 2008 21:06:07 schrieb Jan de Groot:
Yes you can. Actually there's an svn move command which does the same action in one operation.
Does it remove files from the traget dir which are not in the source dir? That's why I have used svn rm before in testing2extra.
No, svn move is just a simple add & delete command that adds the file as new file and removes the old filename. It doesn't merge directories.
Right, what I want is this: delete extra-i686/ move testing-i686/ extra-i686/
I assumed (because Pierre did it this way) that you need to commit the first 'rm' before the 'mv' will go through
I'm telling you now that this is what you must do. There is no way to delete a dir and add it again in the same commit. I think it'l a limitation of the svn working copy implementation vs. a limitation of the repo format.
So... why delete the dir?
Would something like this work?
delete extra-i686/* move testing-i686/* extra-i686/ delete testing-i686
That seems messy because there are svnmerge properties on the directory
On Thu, May 22, 2008 at 2:33 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Thu, May 22, 2008 at 4:23 PM, Travis Willard <travis@archlinux.org> wrote:
On Thu, May 22, 2008 at 4:53 PM, Jason Chu <jason@archlinux.org> wrote:
On Thu, May 22, 2008 at 12:18 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Thu, May 22, 2008 at 2:14 PM, Jan de Groot <jan@jgc.homeip.net> wrote:
On Thu, 2008-05-22 at 21:09 +0200, Pierre Schmitz wrote:
Am Donnerstag, 22. Mai 2008 21:06:07 schrieb Jan de Groot: > Yes you can. Actually there's an svn move command which does the same > action in one operation.
Does it remove files from the traget dir which are not in the source dir? That's why I have used svn rm before in testing2extra.
No, svn move is just a simple add & delete command that adds the file as new file and removes the old filename. It doesn't merge directories.
Right, what I want is this: delete extra-i686/ move testing-i686/ extra-i686/
I assumed (because Pierre did it this way) that you need to commit the first 'rm' before the 'mv' will go through
I'm telling you now that this is what you must do. There is no way to delete a dir and add it again in the same commit. I think it'l a limitation of the svn working copy implementation vs. a limitation of the repo format.
So... why delete the dir?
Would something like this work?
delete extra-i686/* move testing-i686/* extra-i686/ delete testing-i686
That seems messy because there are svnmerge properties on the directory
Yes, the svnmerge properties are on the directory. Also, I believe that the file move will also fail. It has to do with adding something with the same path as something you're trying to delete. You get an annoying error, something like, "such/and/such already marked for deletion". Jason
participants (7)
-
Aaron Griffin
-
Eric Belanger
-
Jan de Groot
-
Jason Chu
-
Pierre Schmitz
-
Tobias Kieslich
-
Travis Willard