So as of yesterday I checked in all frugalware changes I received. I also added the file-conflict progress bar (talk to ya'll on #frugalware). Now, the CVS may be a tad messy right now - and the docs still have some "frugal" instances in there, but the functionality is there. A few changes I made while testing this out: alpm_parse_config additional parameter for the current section. This allows for sections to be declared before include files (this is the way the arch configs currently work). I actually like this more, and it doesn't break anything. I moved the <repo>/<group>/<pkgname> <version> output to look like on of: <repo>/<pkgname> <version> (<group>) or <repo>/<pkgname> <version> This is because, unlike frugalware packages, not all arch packages are grouped, so there was alot of "current/(null)/foobar" output. Also, I think the fake pathing could potentially be confusing for some users. We could probably find a common solution to this here... lemme know if you guys have any suggestions that fit with both arch and frugalware. I also moved the ftplib progress info to the front of the bar, so that the progress bar aligns with the other progressbars. Other than those, I think the functionality is all there. There's some code cleanup I want to do too, but that's unimportant right now. Next on the list is doc cleanup.
2006/10/16, Aaron Griffin <aaronmgriffin@gmail.com>:
So as of yesterday I checked in all frugalware changes I received. I also added the file-conflict progress bar (talk to ya'll on #frugalware).
Now, the CVS may be a tad messy right now - and the docs still have some "frugal" instances in there, but the functionality is there.
Next on the list is doc cleanup.
Wow! That's amazing! Thanks! :-) -- Roman Kyrylych (Роман Кирилич)
On 10/16/06, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
2006/10/16, Aaron Griffin <aaronmgriffin@gmail.com>:
So as of yesterday I checked in all frugalware changes I received. I also added the file-conflict progress bar (talk to ya'll on #frugalware).
Now, the CVS may be a tad messy right now - and the docs still have some "frugal" instances in there, but the functionality is there.
Next on the list is doc cleanup.
Wow! That's amazing! Thanks! :-)
Hooray !! --
Roman Kyrylych (Роман Кирилич) _______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://www.archlinux.org/mailman/listinfo/pacman-dev
2006/10/16, Douglas Andrade <dsandrade@gmail.com>:
On 10/16/06, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
2006/10/16, Aaron Griffin <aaronmgriffin@gmail.com>:
So as of yesterday I checked in all frugalware changes I received. I also added the file-conflict progress bar (talk to ya'll on #frugalware).
Now, the CVS may be a tad messy right now - and the docs still have some "frugal" instances in there, but the functionality is there.
Next on the list is doc cleanup.
Wow! That's amazing! Thanks! :-)
Hooray !!
BTW, phrakture, there are plenty of pacman/makepkg/abs-related bug reports & feature requests in Flyspray. Maybe you can find some time later to close those that are resolved in pacman3 already? Some of them are even reportef by VMiklos and contains his patches, so I'm sure they are implemented now. And there are some very small fixes for abs and makepkg, which IMHO can be implemented now (if they are not fixed already). -- Roman Kyrylych (Роман Кирилич)
2006/10/16, Aaron Griffin <aaronmgriffin@gmail.com>:
So as of yesterday I checked in all frugalware changes I received. I also added the file-conflict progress bar (talk to ya'll on #frugalware).
Hmm.. I just did cvs checkout and pacman is 3.4.0. But Frugalware has 3.4.2 already + some changes after 3.4.2. I'm curious will pacman3 development be in sync now? -- Roman Kyrylych (Роман Кирилич)
On Mon, Oct 16, 2006 at 11:34:42PM +0300, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
Hmm.. I just did cvs checkout and pacman is 3.4.0. But Frugalware has 3.4.2 already + some changes after 3.4.2. I'm curious will pacman3 development be in sync now?
yes, the target is to minimize the difference between the two branches udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org
2006/10/17, VMiklos <vmiklos@frugalware.org>:
On Mon, Oct 16, 2006 at 11:34:42PM +0300, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
Hmm.. I just did cvs checkout and pacman is 3.4.0. But Frugalware has 3.4.2 already + some changes after 3.4.2. I'm curious will pacman3 development be in sync now?
yes, the target is to minimize the difference between the two branches
OK, I feel much better now. :-D BTW, 12 Oct.: makepkg: drop md5 support - but Arch Linux doesn't switch to sha1 yet, though there was a discussion about md5 vs. sha1 vs. md5+sha1 here. :-? -- Roman Kyrylych (Роман Кирилич)
On 10/16/06, VMiklos <vmiklos@frugalware.org> wrote:
On Mon, Oct 16, 2006 at 11:34:42PM +0300, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
Hmm.. I just did cvs checkout and pacman is 3.4.0. But Frugalware has 3.4.2 already + some changes after 3.4.2. I'm curious will pacman3 development be in sync now?
yes, the target is to minimize the difference between the two branches
That's just version numbering anyway. I haven't touched that... I'm not really sure how to tackle it anyway... we've never released a pacman 3 here, and it seems silly to start off with a pacman 3.4.X release.... confusing confusing
2006/10/17, Aaron Griffin <aaronmgriffin@gmail.com>:
On 10/16/06, VMiklos <vmiklos@frugalware.org> wrote:
On Mon, Oct 16, 2006 at 11:34:42PM +0300, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
Hmm.. I just did cvs checkout and pacman is 3.4.0. But Frugalware has 3.4.2 already + some changes after 3.4.2. I'm curious will pacman3 development be in sync now?
yes, the target is to minimize the difference between the two branches
That's just version numbering anyway. I haven't touched that... I'm not really sure how to tackle it anyway... we've never released a pacman 3 here, and it seems silly to start off with a pacman 3.4.X release.... confusing confusing
yeah, there was a question about why 3.4.x in #archlinux few hours ago. BTW, yankees26 tried to compile pacman-lib but failed. Does it compile, or not yet? -- Roman Kyrylych (Роман Кирилич)
On 10/16/06, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
yeah, there was a question about why 3.4.x in #archlinux few hours ago. BTW, yankees26 tried to compile pacman-lib but failed. Does it compile, or not yet?
Sure it does. If you don't have po4a or doxygen installed, you probably want to --disable-po4a --disable-doxygen
On Tue, 17 Oct 2006 00:27:55 +0300 "Roman Kyrylych" <roman.kyrylych@gmail.com> wrote:
yeah, there was a question about why 3.4.x in #archlinux few hours ago. BTW, yankees26 tried to compile pacman-lib but failed. Does it compile, or not yet?
Not sure if the Arch package has been changed yet or not but pacman3 wouldn't compile against the stock libarchive, it needs to be rebuilt. Use ABS to rebuild without the libtool-slay at the end of libarchive, rebuild and then pacman-lib should compile.
On 10/16/06, Cameron Daniel <me@camdaniel.com> wrote:
On Tue, 17 Oct 2006 00:27:55 +0300 "Roman Kyrylych" <roman.kyrylych@gmail.com> wrote:
yeah, there was a question about why 3.4.x in #archlinux few hours ago. BTW, yankees26 tried to compile pacman-lib but failed. Does it compile, or not yet?
Not sure if the Arch package has been changed yet or not but pacman3 wouldn't compile against the stock libarchive, it needs to be rebuilt. Use ABS to rebuild without the libtool-slay at the end of libarchive, rebuild and then pacman-lib should compile.
Actually, it's only pacman-static that fails - the rest builds fine... at some point I want to libtool-slay pacman too 8)
On Mon, 16 Oct 2006 18:24:58 -0500 "Aaron Griffin" <aaronmgriffin@gmail.com> wrote:
Actually, it's only pacman-static that fails - the rest builds fine... at some point I want to libtool-slay pacman too 8)
Yeah but for someone who may not know what they're looking at, the build process fails and they may not look any further. Sound very motivated there, go team :D
On Mon, Oct 16, 2006 at 10:25:50AM -0500, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
So as of yesterday I checked in all frugalware changes I received.
thanks for doing it. a few comments (correct me if at some point i'm wrong): 1) po4a detection is added 3 times to configure.ac 2) you forgot to cvs add the bindings directory, while you added the bindings part to configure.ac 3) po4a support as been added to doc/Makefile.am, but the translations in /doc/po/ are missing 4) you left several NoUpgrade files in pacman.conf while that directive should not be used by default (it is something for users) see http://www.archlinux.org/pipermail/pacman-dev/2006-May/000321.html 5) libalpm/add.c: search for "Cleaning up", added 2 times 6) you've added a new callback parameter to alpm_db_register() which is totally useless imho. the callback is called with the treename (which is a parameter, too) and the database pointer, which is returned. so what's the point of it? 7) in alpm.c: - * @return a void* on success (the value), NULL on error + * @return a char* on success (the value), NULL on error */ void *alpm_conflict_getinfo(pmconflict_t *conflict, unsigned char parm) is this a typo? :) 8) i think you've reverted judd's following change: 2006-07-04 19:48 judd * lib/libalpm/deps.c: bugfix: when looking at provides, defer to the new, to-be-installed package's provisios instead of the the existing package's 9) what is the benefit of this change in Makefile.am? - cd pactest; python pactest.py --test=tests/*.py -p ../src/pacman/pacman --debug=-1 + cd pactest; python pactest.py --test=tests/*.py -p ../src/pacman/pacman --debug=1 it seems to be that this will disable all logging except debug. why is this good? 10) i think you forgot to cvs add the /pactest/tests/ directory 11) i think you forgot to add the relevant copyright lines to scripts/makepkg 12) you haven't removed src/pacman/db.[ch] while noone uses the functions provided by them also (as i promised earlier) i've corrected the copyright lines in our tree according to the current state of the cvs udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org
On 10/19/06, VMiklos <vmiklos@frugalware.org> wrote:
1) po4a detection is added 3 times to configure.ac
Fixed. I've noticed one or two other instances of triple-insertions...
2) you forgot to cvs add the bindings directory, while you added the bindings part to configure.ac
Bindings are here: http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/bindings/?cvsroot=Pacman What do you mean?
3) po4a support as been added to doc/Makefile.am, but the translations in /doc/po/ are missing
Not sure what you mean - the only translations I have from the patch are hungarian.
4) you left several NoUpgrade files in pacman.conf while that directive should not be used by default (it is something for users)
According to CVS, NoUpgrade was never removed. This is the latest: http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/etc/Attic/pacman.conf?rev=HEAD&search=None&hideattic=1&cvsroot=Pacman&only_with_tag=HEAD&content-type=text/vnd.viewcvs-markup
5) libalpm/add.c: search for "Cleaning up", added 2 times
Fixed in CVS.
6) you've added a new callback parameter to alpm_db_register() which is totally useless imho. the callback is called with the treename (which is a parameter, too) and the database pointer, which is returned. so what's the point of it?
The point is that I changed this function to return the existing DB in an attempt to reregister, in place of returning null. It seems stupid to let this fail: [current] Server = a [current] Server = b Every config file parser I've seen for sectioned configs ([section name]) parses this as if they were all one section. As such, the change requires the callback because only db_register knows when the database is new or old. It's a rather trivial change, and not "totally useless", as it allows for more valid config file handling.
7) in alpm.c:
- * @return a void* on success (the value), NULL on error + * @return a char* on success (the value), NULL on error */ void *alpm_conflict_getinfo(pmconflict_t *conflict, unsigned char parm)
is this a typo? :)
I didn't touch those comments... fixed in CVS though
8) i think you've reverted judd's following change: 2006-07-04 19:48 judd
* lib/libalpm/deps.c: bugfix: when looking at provides, defer to the new, to-be-installed package's provisios instead of the the existing package's
Ah crap... didn't notice that one, I assumed your patches took this into account. I will fix this later, as it's a shade more complicated than editing a few lines.
9) what is the benefit of this change in Makefile.am?
- cd pactest; python pactest.py --test=tests/*.py -p ../src/pacman/pacman --debug=-1 + cd pactest; python pactest.py --test=tests/*.py -p ../src/pacman/pacman --debug=1
That was a mistake on my part that shouldn't have been checked in. I was not getting debug output, so messed with the param.... later I found the 2>&1 > logfile redirection and therefore added the nolog parameter. Fixed in CVS.
10) i think you forgot to cvs add the /pactest/tests/ directory They show up for me: http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/pactest/tests/?search=None&hideattic=1&cvsroot=Pacman&only_with_tag=HEAD
11) i think you forgot to add the relevant copyright lines to scripts/makepkg
Ah, I didn't change mackepkg so didn't check that - fixed in CVS
12) you haven't removed src/pacman/db.[ch] while noone uses the functions provided by them
Done. Thanks alot.
hi, first, thanks for your fast reply :) On Thu, Oct 19, 2006 at 10:22:27AM -0500, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
Bindings are here: http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/bindings/?cvsroot=Pacman What do you mean?
vmiklos@vmobile:~/scm/cvs/pacman-lib$ cvs update cvs update: Updating . cvs update: Updating doc cvs update: Updating etc cvs update: Updating lib cvs update: Updating lib/libalpm cvs update: Updating lib/libalpm/po cvs update: Updating lib/libftp cvs update: Updating pactest cvs update: Updating scripts cvs update: Updating src cvs update: Updating src/pacman cvs update: Updating src/pacman/po cvs update: Updating src/util vmiklos@vmobile:~/scm/cvs/pacman-lib$ ls AUTHORS autogen.sh* configure.ac CVS/ etc/ Makefile.am pactest/ scripts/ TODO autoclean.sh* ChangeLog.bak COPYING doc/ lib/ NEWS README src/ TODO.autoconf strange.
3) po4a support as been added to doc/Makefile.am, but the translations in /doc/po/ are missing
Not sure what you mean - the only translations I have from the patch are hungarian.
vmiklos@vmobile:~/scm/cvs/pacman-lib$ ls doc/po /usr/bin/ls: doc/po: No such file or directory vmiklos@vmobile:~/darcs/pacman$ ls doc/po hu.po hu.po~ pacman.pot
4) you left several NoUpgrade files in pacman.conf while that directive should not be used by default (it is something for users)
According to CVS, NoUpgrade was never removed. This is the latest: http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/etc/Attic/pacman.conf?rev=HEAD&search=None&hideattic=1&cvsroot=Pacman&only_with_tag=HEAD&content-type=text/vnd.viewcvs-markup
yes, but those files should be marked as backup in the relevant packages instead of simply specifying them as noupgrade. i mean, since the following change: 2006-01-22 03:30 judd * lib/libalpm/add.c: changed behaviour with original=X,current=Y,new=Z backup scenario -- install new file as .pacnew and keep old one in place there is no good reason to list config files both in backup() and in the noupgrade list. noupgrade is for users to mark files which are not in the packages' backup()
6) you've added a new callback parameter to alpm_db_register() which is totally useless imho. the callback is called with the treename (which is a parameter, too) and the database pointer, which is returned. so what's the point of it?
The point is that I changed this function to return the existing DB in an attempt to reregister, in place of returning null. It seems stupid to let this fail:
[current] Server = a [current] Server = b
Every config file parser I've seen for sectioned configs ([section name]) parses this as if they were all one section. As such, the change requires the callback because only db_register knows when the database is new or old. It's a rather trivial change, and not "totally useless", as it allows for more valid config file handling.
hm. but still, now alpm_db_update() requires a second parameter that will be always NULL in all frontends. what about adding an _alpm_db_update() function with the callback so that alpm_db_update() could be still called without specifying a callback?
8) i think you've reverted judd's following change: 2006-07-04 19:48 judd
* lib/libalpm/deps.c: bugfix: when looking at provides, defer to the new, to-be-installed package's provisios instead of the the existing package's
Ah crap... didn't notice that one, I assumed your patches took this into account. I will fix this later, as it's a shade more complicated than editing a few lines.
i just did a new diff to merge your changes and noticed that the diff would revert judd's change in our tree :)
10) i think you forgot to cvs add the /pactest/tests/ directory They show up for me: http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/pactest/tests/?search=None&hideattic=1&cvsroot=Pacman&only_with_tag=HEAD
vmiklos@vmobile:~/scm/cvs/pacman-lib$ ls pactest/ COPYING ChangeLog TODO pmdb.py* pmfile.py* pmrule.py* util.py* CVS/ README pactest.py* pmenv.py* pmpkg.py* pmtest.py* hmm. maybe this is a cvs bug - or God knows, this is the 3rd missing directory after cvs update udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org
On Thu, 19 Oct 2006 23:17:14 +0200 VMiklos <vmiklos@frugalware.org> wrote:
hmm. maybe this is a cvs bug - or God knows, this is the 3rd missing directory after cvs update
Just a quick note in case you were forgetting it - to get new directories, use cvs update -d Instead of just cvs update -- Travis
On Thu, Oct 19, 2006 at 06:05:51PM -0400, Travis Willard <travisw@wmpub.ca> wrote:
Just a quick note in case you were forgetting it - to get new directories, use
cvs update -d
Instead of just cvs update
thanks, i learned something new again :) /me hists himself with the big red cvs book.. udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org
On Thu, Oct 19, 2006 at 11:17:14PM +0200, VMiklos <vmiklos@frugalware.org> wrote:
vmiklos@vmobile:~/scm/cvs/pacman-lib$ cvs update cvs update: Updating . cvs update: Updating doc cvs update: Updating etc cvs update: Updating lib cvs update: Updating lib/libalpm cvs update: Updating lib/libalpm/po cvs update: Updating lib/libftp cvs update: Updating pactest cvs update: Updating scripts cvs update: Updating src cvs update: Updating src/pacman cvs update: Updating src/pacman/po cvs update: Updating src/util vmiklos@vmobile:~/scm/cvs/pacman-lib$ ls AUTHORS autogen.sh* configure.ac CVS/ etc/ Makefile.am pactest/ scripts/ TODO autoclean.sh* ChangeLog.bak COPYING doc/ lib/ NEWS README src/ TODO.autoconf
strange.
oh, nevermind. rm -rf pacman-lib, cvs co from scratch solved the issue yet another reason to switch from cvs to darcs :) udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org
Out of order: On 10/19/06, VMiklos <vmiklos@frugalware.org> wrote:
Bindings are here: http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/bindings/?cvsroot=Pacman What do you mean?
3) po4a support as been added to doc/Makefile.am, but the translations in /doc/po/ are missing
Not sure what you mean - the only translations I have from the patch are hungarian.
10) i think you forgot to cvs add the /pactest/tests/ directory They show up for me: http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/pactest/tests/?search=None&hideattic=1&cvsroot=Pacman&only_with_tag=HEAD
hmm. maybe this is a cvs bug - or God knows, this is the 3rd missing directory after cvs update
Can anyone else reproduce this? It's possible I'm just cvs-inept and missed something important - but they show up in viewcvs....
4) you left several NoUpgrade files in pacman.conf while that directive should not be used by default (it is something for users)
According to CVS, NoUpgrade was never removed. This is the latest: http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/etc/Attic/pacman.conf?rev=HEAD&search=None&hideattic=1&cvsroot=Pacman&only_with_tag=HEAD&content-type=text/vnd.viewcvs-markup
yes, but those files should be marked as backup in the relevant packages instead of simply specifying them as noupgrade. i mean, since the following change:
2006-01-22 03:30 judd
* lib/libalpm/add.c: changed behaviour with original=X,current=Y,new=Z backup scenario -- install new file as .pacnew and keep old one in place
there is no good reason to list config files both in backup() and in the noupgrade list. noupgrade is for users to mark files which are not in the packages' backup()
Right, all I was saying has to do with the "left" portion of what you said. I didn't really leave anything as I was never aware that they needed to be removed... I will look into it, as I don't *yet) have all the details of this change.
6) you've added a new callback parameter to alpm_db_register() which is totally useless imho. the callback is called with the treename (which is a parameter, too) and the database pointer, which is returned. so what's the point of it?
The point is that I changed this function to return the existing DB in an attempt to reregister, in place of returning null. It seems stupid to let this fail:
[current] Server = a [current] Server = b
Every config file parser I've seen for sectioned configs ([section name]) parses this as if they were all one section. As such, the change requires the callback because only db_register knows when the database is new or old. It's a rather trivial change, and not "totally useless", as it allows for more valid config file handling.
hm. but still, now alpm_db_update() requires a second parameter that will be always NULL in all frontends. what about adding an _alpm_db_update() function with the callback so that alpm_db_update() could be still called without specifying a callback?
On a personal note, I don't have a problem with "mostly null" parameters - many ANSI C and POSIX functions are invoked this way. This would be much easier if it were C++ (note: I'm being snarky, I prefer C++ by leaps and bounds over C - C++ would shrik libalpm nearly in half... but that's not my decision, heh). 8) I guess having two functions is not a huge deal.... I can add that.
On Thu, Oct 19, 2006 at 05:11:54PM -0500, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On a personal note, I don't have a problem with "mostly null" parameters - many ANSI C and POSIX functions are invoked this way. This would be much easier if it were C++ (note: I'm being snarky, I prefer C++ by leaps and bounds over C - C++ would shrik libalpm nearly in half... but that's not my decision, heh). 8)
my argument here is having an extra parameter for a public function that is used only internally. a logical problem
I guess having two functions is not a huge deal.... I can add that.
then please do it. thanks in advance :) udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org
On 10/19/06, VMiklos <vmiklos@frugalware.org> wrote:
On Thu, Oct 19, 2006 at 05:11:54PM -0500, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On a personal note, I don't have a problem with "mostly null" parameters - many ANSI C and POSIX functions are invoked this way. This would be much easier if it were C++ (note: I'm being snarky, I prefer C++ by leaps and bounds over C - C++ would shrik libalpm nearly in half... but that's not my decision, heh). 8)
my argument here is having an extra parameter for a public function that is used only internally. a logical problem
It appears that pacman only ever uses db_register to register the local db. This seems like something which should be handled internally... regardless, I added the function.
On Fri, Oct 20, 2006 at 01:27:16AM -0500, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
It appears that pacman only ever uses db_register to register the local db. This seems like something which should be handled internally...
in some cases using just db_register() is useful. at least we us it in our testsuite (when we find dependency problems in the package database) and in the iso generator (when you have to put packages to several cds sorted by deps)
regardless, I added the function.
thanks :) udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org
On Thu, Oct 19, 2006 at 03:17:06PM +0200, VMiklos <vmiklos@frugalware.org> wrote:
thanks for doing it. a few comments (correct me if at some point i'm wrong):
a few more: 1) in alpm.i: -%pointer_cast(void *, long, void_to_long); +%pointer_cast(char *, long *, void_to_long); is this change a typo? 2) the _generated_ manpages are now under version control in /doc/man3. i think they should be cvs removed 3) in alpm.c: * @param level if true, then forces the update, otherwise update only in case - * the database isn't up to date * @param db pointer to the package database to update i think this is by accident, too 4) in alpm.c, too: -/** @defgroup alpm_conflict File Conflicts Functions +/** @defgroup alpm_dep File Conflicts Functions wtf? :) 5) alpm.h: - PM_ERR_MEMORY = 1, + PM_ERR_MEMORY = 2, i think this is just a workaround for the functions returning 1 instead of -1 on error. what about reverting this change, since as far as i see you've already fixed those problematic functions? 6) in alpm/db.c: if(db->path == NULL) { _alpm_log(PM_LOG_ERROR, _("malloc failed: could not allocate %d bytes"), - strlen(root)+strlen(dbpath)+strlen(treename)+2); + strlen(root)+strlen(dbpath)+strlen(treename)+2); FREE(db); RET_ERR(PM_ERR_MEMORY, NULL); } a) when i break a long line to shorter ones, then i indent the !=1st ones with 1 tab. vim automatically adds 2 ones. but why chaning the 2 tabs to 3 ones? b) please use tabs instead of 2 spaces (there are more than one example for this problem) 7) still in db.c: match = 1; + } else { } why adding such empty statements? (Judd's provides-related bugfix is still reverted) udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org
I didn't touch any of alpm.i or the doxygen comments at all... so I have no idea where these changes come from. On 10/21/06, VMiklos <vmiklos@frugalware.org> wrote:
1) in alpm.i: Fixed
2) the _generated_ manpages are now under version control in /doc/man3. i think they should be cvs removed Fixed
3) in alpm.c: 4) in alpm.c, too: Fixed
5) alpm.h:
- PM_ERR_MEMORY = 1, + PM_ERR_MEMORY = 2,
i think this is just a workaround for the functions returning 1 instead of -1 on error. what about reverting this change, since as far as i see you've already fixed those problematic functions?
Hmmm, I'd still like to keep this just in case there are dangling 1 returns. There should be no harm in changing this value at all. There is nowhere where it should ever be used, and no one should ever care about these values... I mean, does anyone know the value of EDEADLK?
6) in alpm/db.c: if(db->path == NULL) { _alpm_log(PM_LOG_ERROR, _("malloc failed: could not allocate %d bytes"), - strlen(root)+strlen(dbpath)+strlen(treename)+2); + strlen(root)+strlen(dbpath)+strlen(treename)+2); FREE(db); RET_ERR(PM_ERR_MEMORY, NULL); }
a) when i break a long line to shorter ones, then i indent the !=1st ones with 1 tab. vim automatically adds 2 ones. but why chaning the 2 tabs to 3 ones?
:set cinoptions+=(0 This aligns new lines with an unclosed ( on the previous line. It is the way I prefer this.
b) please use tabs instead of 2 spaces
noet should be set on all source files, inserting tabs instead of spaces. If noet is not set, please let me know.
(there are more than one example for this problem)
Formatting has not been discussed anywhere beyond the modelines in each file, which vim always respects. I don't think calling this a "problem" is correct.
7) still in db.c: Fixed.
(Judd's provides-related bugfix is still reverted) Yes I'm aware, I never said it was fixed - I said i was going to do it when I had the time.
On Sat, Oct 21, 2006 at 02:20:18PM -0500, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
5) alpm.h:
- PM_ERR_MEMORY = 1, + PM_ERR_MEMORY = 2,
i think this is just a workaround for the functions returning 1 instead of -1 on error. what about reverting this change, since as far as i see you've already fixed those problematic functions?
Hmmm, I'd still like to keep this just in case there are dangling 1 returns. There should be no harm in changing this value at all. There is nowhere where it should ever be used, and no one should ever care about these values... I mean, does anyone know the value of EDEADLK?
35. to be honest the problem is that this is an api change and we use already alpm in many places. an unnecessary recompile of all the packages should be avoided if possible. yes, i know that the answer now will be "we always said pacman3 is not yet ready, we said don't use it yet - now see, why can't you guys wait?" :) so it's up to you. currently such an api change for you is not a problem, for us it is
This aligns new lines with an unclosed ( on the previous line. It is the way I prefer this.
b) please use tabs instead of 2 spaces
noet should be set on all source files, inserting tabs instead of spaces. If noet is not set, please let me know.
(there are more than one example for this problem)
Formatting has not been discussed anywhere beyond the modelines in each file, which vim always respects. I don't think calling this a "problem" is correct.
my first opensource project where i started hacking was MPlayer and there any patch that contained whitespace changes was rejected with a short "whitespace changes mixed with functional changes, rejected" message, so i'm used to do things this way. i'll try to stop blaming you because of your cosmetics ;)
Yes I'm aware, I never said it was fixed - I said i was going to do it when I had the time.
ok and thank you for your fixes udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org
On 10/21/06, VMiklos <vmiklos@frugalware.org> wrote:
35. to be honest the problem is that this is an api change and we use already alpm in many places. an unnecessary recompile of all the packages should be avoided if possible. yes, i know that the answer now will be "we always said pacman3 is not yet ready, we said don't use it yet - now see, why can't you guys wait?" :)
so it's up to you. currently such an api change for you is not a problem, for us it is
Ok, so here's what we'll do. I'll revert to using 1, for now... at a later date I'd like to switch it to a higher number, just to prevent some random conflicts... it's rather unimportant, but it's worthwhile. Fixed in cvs.
my first opensource project where i started hacking was MPlayer and there any patch that contained whitespace changes was rejected with a short "whitespace changes mixed with functional changes, rejected" message, so i'm used to do things this way. i'll try to stop blaming you because of your cosmetics ;)
Yeah, I've contributed to projects which said tabs were equally as dumb. i.e. vim's scripts require :set et ts=8 sw=8:. In 99% of cases it's up to the author. In this case, I'll let judd do a "coding format" writeup and we can all use that. On a personal note, I prefer :set et ts=4 sw=4: - I hate tabs, but that's a holy war I don't really care to get into. Personally, I could care less about whitespace, because i use vim. If the modelines are proper, gg=G fixes any whitespace issues...
Yes I'm aware, I never said it was fixed - I said i was going to do it when I had the time.
ok and thank you for your fixes
Should be fixed now... at least it compiles and succeeds with all pactests, and runs fine... I didn't really test it because I need to head out in like 10 minutes, but it should be in CVS. I'll work on this some when I get home in 5 hours or so...
participants (6)
-
Aaron Griffin
-
Cameron Daniel
-
Douglas Andrade
-
Roman Kyrylych
-
Travis Willard
-
VMiklos