[arch-dev-public] Namcap maintainer
Hi devs. With your approval and permission I would like to be added to the maintainers for Namcap. It aligns well with my interests and does not seem to have any active maintainer at present. I'd like to immediately get through the backlog of patches, feature requests and bug reports (mine included). -Kyle http://kmkeen.com
On 14/12/14 23:20, keenerd wrote:
Hi devs.
With your approval and permission I would like to be added to the maintainers for Namcap. It aligns well with my interests and does not seem to have any active maintainer at present. I'd like to immediately get through the backlog of patches, feature requests and bug reports (mine included).
I am happy for this to happen. I am told that we will need some patches to be applied with the pacman-4.2 release, so getting an active maintainer now would be a good thing. If no-one objects soon, I will give permissions to Kyle. Allan
On Sun, Dec 14, 2014 at 11:23:40PM +1000, Allan McRae wrote:
On 14/12/14 23:20, keenerd wrote:
Hi devs.
With your approval and permission I would like to be added to the maintainers for Namcap. It aligns well with my interests and does not seem to have any active maintainer at present. I'd like to immediately get through the backlog of patches, feature requests and bug reports (mine included).
I am happy for this to happen. I am told that we will need some patches to be applied with the pacman-4.2 release, so getting an active maintainer now would be a good thing.
If no-one objects soon, I will give permissions to Kyle.
Allan
namcap doesn't need attention -- it's pyalpm which needs it for the 4.2 release. I've got a few patches which work towards this (and make namcap work with pacman-git), but they need further help from someone who's actually interested in development to finish them off and make pycman fully useful again. No objections to Kyle taking over namcap alone, but I have to ask, Kyle, are you interested in taking on pyalpm as well? dR
On 12/14/14, Dave Reisner <d@falconindy.com> wrote:
No objections to Kyle taking over namcap alone, but I have to ask, Kyle, are you interested in taking on pyalpm as well?
Not terribly interested, but I guess I can if I have to. Attached is a quick 30 minute hack that lets pyalpm build against 4.2 and restores namcap functionality. Pycman probably suffers greatly. -Kyle http://kmkeen.com
On Fri, Dec 19, 2014 at 08:03:37AM -0500, keenerd wrote:
On 12/14/14, Dave Reisner <d@falconindy.com> wrote:
No objections to Kyle taking over namcap alone, but I have to ask, Kyle, are you interested in taking on pyalpm as well?
Not terribly interested, but I guess I can if I have to. Attached is a quick 30 minute hack that lets pyalpm build against 4.2 and restores namcap functionality. Pycman probably suffers greatly.
Almost. Missing from this patch is handling for the new 'Usage' key in repo sections of the config parser.
-Kyle http://kmkeen.com
--- src/transaction.c 2013-04-01 08:21:10.000000000 -0400 +++ src/transaction.c 2014-12-19 07:24:54.595390109 -0500 @@ -30,7 +30,7 @@ /** Transaction callbacks */ extern PyObject *global_py_callbacks[N_CALLBACKS];
-void pyalpm_eventcb(alpm_event_t event, void* data1, void *data2) { +void pyalpm_eventcb(alpm_event_type_t event, void* data1, void *data2) {
This is wrong. pyalpm_eventcb must match alpm_cb_event, which is defined as: typedef void (*alpm_cb_event)(alpm_event_t *);
const char *eventstr; PyObject *obj1 = Py_None; PyObject *obj2 = Py_None; @@ -59,6 +59,8 @@ case ALPM_EVENT_INTERCONFLICTS_DONE: eventstr = "Done checking inter conflicts"; break; + /* deprecated in 4.2 + * leaving these commented out while finding 4.2 equivalents
data1 and data2 are now pulled from the event itself, so you'll use something like this in place: obj1 = pyalpm_package_from_pmpkg(event.package_operation.oldpkg); obj2 = pyalpm_package_from_pmpkg(event.package_operation.newpkg);
case ALPM_EVENT_ADD_START: eventstr = "Adding a package"; obj1 = pyalpm_package_from_pmpkg(data1); @@ -86,6 +88,7 @@ obj1 = pyalpm_package_from_pmpkg(data1); obj2 = pyalpm_package_from_pmpkg(data2); break; + */ case ALPM_EVENT_INTEGRITY_START: eventstr = "Checking integrity"; break; @@ -114,12 +117,26 @@ case ALPM_EVENT_DISKSPACE_DONE: eventstr = "Done checking disk space"; break; + /* deprecated in 4.2 case ALPM_EVENT_OPTDEP_REQUIRED: + */ case ALPM_EVENT_DATABASE_MISSING: case ALPM_EVENT_KEYRING_START: case ALPM_EVENT_KEYRING_DONE: case ALPM_EVENT_KEY_DOWNLOAD_START: case ALPM_EVENT_KEY_DOWNLOAD_DONE: + /* new in 4.2 */ + case ALPM_EVENT_PACKAGE_OPERATION_START: + case ALPM_EVENT_PACKAGE_OPERATION_DONE: + case ALPM_EVENT_RETRIEVE_DONE: + case ALPM_EVENT_RETRIEVE_FAILED: + case ALPM_EVENT_PKGDOWNLOAD_START: + case ALPM_EVENT_PKGDOWNLOAD_DONE: + case ALPM_EVENT_PKGDOWNLOAD_FAILED: + case ALPM_EVENT_OPTDEP_REMOVAL: + case ALPM_EVENT_PACNEW_CREATED: + case ALPM_EVENT_PACSAVE_CREATED: + case ALPM_EVENT_PACORIG_CREATED: default: eventstr = "unknown event"; }
I have done both on pyalpm yesterday, sorry for being away. I am very happy if anyone can take care of namcap. Remy. Le 19 déc. 2014 14:45, "Dave Reisner" <d@falconindy.com> a écrit :
On Fri, Dec 19, 2014 at 08:03:37AM -0500, keenerd wrote:
On 12/14/14, Dave Reisner <d@falconindy.com> wrote:
No objections to Kyle taking over namcap alone, but I have to ask, Kyle, are you interested in taking on pyalpm as well?
Not terribly interested, but I guess I can if I have to. Attached is a quick 30 minute hack that lets pyalpm build against 4.2 and restores namcap functionality. Pycman probably suffers greatly.
Almost. Missing from this patch is handling for the new 'Usage' key in repo sections of the config parser.
-Kyle http://kmkeen.com
--- src/transaction.c 2013-04-01 08:21:10.000000000 -0400 +++ src/transaction.c 2014-12-19 07:24:54.595390109 -0500 @@ -30,7 +30,7 @@ /** Transaction callbacks */ extern PyObject *global_py_callbacks[N_CALLBACKS];
-void pyalpm_eventcb(alpm_event_t event, void* data1, void *data2) { +void pyalpm_eventcb(alpm_event_type_t event, void* data1, void *data2) {
This is wrong. pyalpm_eventcb must match alpm_cb_event, which is defined as:
typedef void (*alpm_cb_event)(alpm_event_t *);
const char *eventstr; PyObject *obj1 = Py_None; PyObject *obj2 = Py_None; @@ -59,6 +59,8 @@ case ALPM_EVENT_INTERCONFLICTS_DONE: eventstr = "Done checking inter conflicts"; break; + /* deprecated in 4.2 + * leaving these commented out while finding 4.2 equivalents
data1 and data2 are now pulled from the event itself, so you'll use something like this in place:
obj1 = pyalpm_package_from_pmpkg(event.package_operation.oldpkg); obj2 = pyalpm_package_from_pmpkg(event.package_operation.newpkg);
case ALPM_EVENT_ADD_START: eventstr = "Adding a package"; obj1 = pyalpm_package_from_pmpkg(data1); @@ -86,6 +88,7 @@ obj1 = pyalpm_package_from_pmpkg(data1); obj2 = pyalpm_package_from_pmpkg(data2); break; + */ case ALPM_EVENT_INTEGRITY_START: eventstr = "Checking integrity"; break; @@ -114,12 +117,26 @@ case ALPM_EVENT_DISKSPACE_DONE: eventstr = "Done checking disk space"; break; + /* deprecated in 4.2 case ALPM_EVENT_OPTDEP_REQUIRED: + */ case ALPM_EVENT_DATABASE_MISSING: case ALPM_EVENT_KEYRING_START: case ALPM_EVENT_KEYRING_DONE: case ALPM_EVENT_KEY_DOWNLOAD_START: case ALPM_EVENT_KEY_DOWNLOAD_DONE: + /* new in 4.2 */ + case ALPM_EVENT_PACKAGE_OPERATION_START: + case ALPM_EVENT_PACKAGE_OPERATION_DONE: + case ALPM_EVENT_RETRIEVE_DONE: + case ALPM_EVENT_RETRIEVE_FAILED: + case ALPM_EVENT_PKGDOWNLOAD_START: + case ALPM_EVENT_PKGDOWNLOAD_DONE: + case ALPM_EVENT_PKGDOWNLOAD_FAILED: + case ALPM_EVENT_OPTDEP_REMOVAL: + case ALPM_EVENT_PACNEW_CREATED: + case ALPM_EVENT_PACSAVE_CREATED: + case ALPM_EVENT_PACORIG_CREATED: default: eventstr = "unknown event"; }
On 22/12/14 06:07, Rémy Oudompheng wrote:
I have done both on pyalpm yesterday, sorry for being away. I am very happy if anyone can take care of namcap.
I gave Kyle a git-shell account with access to namcap. Allan
participants (4)
-
Allan McRae
-
Dave Reisner
-
keenerd
-
Rémy Oudompheng