rpm-software-management / createrepo_c Goto Github PK

Some parameters (like "${LIBXML2_INCLUDE_DIR}" and "${LIB_INSTALL_DIR}") are passed to CMake commands in your build scripts without enclosing them by quotation marks. I see that these places will result in build difficulties if the contents of the used variables will contain special characters like semicolons.

I would recommend to apply advices from a wiki article.

It would be handy to be able to redirect these paths to another location to cope with diskspace etc, or at least respect $TMPDIR

Please document which exceptions can be raised if path of createrepo_c.XmlFile.__init__ does not point to a writeable location.
It also seems that createrepo_c.XmlFile.add_pkg can raise some exceptions, right?

It would save me few letters and one variable name if I could create the createrepo_c.RepomdRecord using a single function :)

E.g. it could be:

• createrepo_c.RepomdRecord(typename, filename, createrepo_c.SHA256) and it will create a "filled" record
• or similarly createrepo_c.RepomdRecord.create_filled(typename, filename, createrepo_c.SHA256)
• or even createrepo_c.RepomdRecord.filled_from_file(xmlfile, createrepo_c.SHA256)
• or even repomd.set_record_auto(typename, filename, createrepo_c.SHA256)
• or even repomd.set_filerecord(xmlfile, createrepo_c.SHA256)

(it overlaps with #19)

Would you like to add more error handling for return values from functions like the following?

• printf ⇒ main
• sigaction ⇒ cr_set_cleanup_handler

In my case (I don't create the sqlite files), it's much easier/nicer to use createrepo_c.XmlFile than createrepo_c.PrimaryXmlFile and friends. However:

• to create an instance of createrepo_c.XmlFile, I need a type constant (e.g. createrepo_c.XMLFILE_PRIMARY)
• I need the name of the type (e.g. primary) as well to compose the file name (e.g. path/primary.xml.gz) - (Well, I don't need it. The name can be arbitrary. But it's a common practice to use these names.)
• I need the name of the type to refer to the file in a createrepo_c.RepomdRecord instance

I can think of multiple solutions:

• there can be a mapping from type constants to their names and/or the opposite mapping
• there can be a factory function that creates file instances for given type constant (optionally with the default file name)
• there can be a "builder" that has an add_pkg method and a dump method (it will create all the needed files in a given directory)
• there can be a function that transforms a metadata file into a createrepo_c.RepomdRecord
• the createrepo_c.Repomd class can have a method that does the same as set_record but accepts metadata files
• the createrepo_c.XmlFile.__init__ can accept type names
• the createrepo_c.RepomdRecord.__init__ can accept the type constants

but I don't insist on any of them.

I'd like to be able to host a repository on a storage service like s3 or google storage, and be able to add RPMs without having to download the entire repository.

I can approximate this by running 'createrepo' locally with an a baseurl matching the remote repository, and the running merge repo on the remote repository and the local one. But this adds a baseurl to all the packages, rather than having none.

When there is an issue opening a file (for example, a broken symlink), the error is reported, however the exit status still reports success.

The original createrepo returns failure if an error occurs opening a file. While I really, really want to use createrepo_c because of the amazing speed, until this is fixed I have no choice but to use the older, slower, createrepo.

I deployed createrepo_c on Copr. But after few days, I found that there exist several residual .repodata directory.
I do not have reproducer how this can happen, but this happen.

It would be much better if the createrepo_c would name that directory .repodata-$PID
and just give warning if another .repodata-* directory exist.

This way we user get same information, while on massive scale (as is Copr) flipping critical to warning would allow better continuity of service.

Please document which exceptions can be raised if path of createrepo_c.Metadata.locate_and_load_xml does not point to a readable location or if no repository is found.

I appreciate the performance improvement of createrepo_c, and was wondering if repoclosure_c was on the horizon?

6.x & 7.x of the distros don't require the .xml version of the metadata, only the .sqlite files. https://github.com/heroldus/updaterepo disabled the .xml files to speed up creation/updates. createrepo_c should add an option to do the same.

The example createrepo_c/examples/python/simple_createrepo.py calls createrepo_c.XmlFile.set_num_of_pkgs. It seems that my code works the same even if I just add the packages without setting the number. Could you please extend the documentation wrt why should we call createrepo_c.XmlFile.set_num_of_pkgs?

I have ci system that build packages and upload artifacts to openstack swift.
So for example i have pkg-example that produces example-0.0.1.rpm and example-libs-0.0.1.rpm inside /repo/x86_64/

each step runs on docker container that does not have persistent storage and after container dies data removed...

1. i generate rpmmd via createrepo_c inside /repo/repodata
2. upload /repo to openstack swift to public/staging/example/ (so i can add this via repo and test package on all my systems without affecting other test nodes
3. if testing on some nodes are fine, i do mergerepo_c with --repo url that points to public/staging and public/staging/example with output to /repo and upload /repo to public/staging/ (so on this step all staging nodes see the package and i can test on more nodes)
4. if testing on all staging nodes are fine i do upload resulted rpms on public/release/example
   and do mergerepo_c with --repo pointed to public/release/ and public/release/example.
   So all production nodes sees that new package.

My problem - mergerepo_c sees that public/release have older package version and in resulted metadata present only this old version, that absent from public/release/example/.
I can use --all switch, but in this case in metadata i have all package versions, that are stalre already and may be cleanup..

I can rsync all the time packages to use createrepo_c --update because it expensive (i think)
How can i deal with my workflow or how can i change it...?

P.S. I know about mounting openstack swift container via fuse, but i'm try to avoid it because in this case i need privileged docker container (to access to /dev/fuse)

Currently createrepo_c offers a Python 2 API, but it does not offer a Python 3 API to go with it.

Please add a Python 3 API to createrepo_c for those who want to have their programs use Python 3 instead of Python 2.

I have a repo with many many thousands of packages in it. The repos are updated by a scheduled job that know exactly while packages have been updated/added/deleted, but as far as I'm aware there's no way to tell createrepo_c --update to only bother looking for changes in those packages. As far as I'm aware, --pkglist and/or --includepkg with the --update option won't do this, as they'll remove the packages that don't match, I believe. Maybe the --keep-all-metadata option?

Either that isn't currently possible, or the man pages could use some clarifying.

If the RPM spec erroneously contains ANSI escape sequences (I have only tested this in %description), then those bytes are passed into the repo metadata when createrepo_c is called.

This becomes a problem when some parsers (at least that from python's sqlite module), try to parse this and they crash and burn.

createrepo on the other hand avoids this by stripping out the ANSI code.

This was tested using the createrepo_c-0.2.1-1 RPM

Package managers such as dnf and zypper have the ability to verify signatures of metadata if it is signed. In fact, for zypper, this is the default behavior and it complains when the repodata isn't signed.

However, how to do this isn't that well-known, and it would make sense to incorporate the functionality into the createrepo_c suite of tools.

gzip now accepts the --rsyncable option. This option is accepted in all modes, but has effect only when compressing: it makes the resulting output more amenable to efficient use of rsync. For example, when a large input file gets a small change, a gzip --rsyncable image of that file will remain largely unchanged, too. Without --rsyncable, even a tiny change in the input could result in a totally different gzip-compressed output file.

http://savannah.gnu.org/forum/forum.php?forum_id=8495

Please use --rsyncable when compressing package metadata using gzip (provided it's recent enough). This will help mirrors pulling compose updates. Thank you.

A lot of people ship free and nonfree code in addon yum repos for Fedora. They add the rpms to a directory, run createrepo_c and then tell the world about their awesome new repo. Some even get selected by the Fedora workstation group to be included by default in Fedora. The new users fire up gnome-software or apper and searches for the awesome new tool, but nothing is found. I normally have to point them at https://blogs.gnome.org/hughsie/2016/04/27/3rd-party-fedora-repositories-and-appstream/ and get them to update their release tooling.

Could we move to a model where createrepo_c automatically generates the AppStream metadata (either default on, or default off) by calling the appstream-builder executable if it is installed? The other alternative is I write a patch for createrepo_c to use libappstream-builder.so, but that has some deps that you might find unpalatable. I'm open for ideas and am willing to write patches if you agree if this is something you'd permit me to do.

Thanks!

In Spacewalk, repos can be configured using a different checksum method for the XML file entries in repomd.xml and the RPM entries in primary.xml. (Referred to as "checksum type" and "RPM checksum type".)

Currently it's not possible to make createrepo_c generate repos in this way since it only takes a single --checksum argument.

It would be useful if createrepo_c supported setting both checksum types independently so that it can be used to generate repos configured in this way.

It would save me one variable name if createrepo_c.XmlFile instances could provide their file names :)

If I pass a Unicode string to createrepo_c.package_from_rpm (e.g. createrepo_c.package_from_rpm(path, location_href=u'foo')), it seems to work while package.location_href = u'foo' causes TypeError: String or None expected!. I think that both should behave the same wrt to Unicode strings.

createrepo_c/src/misc.c:421]: (error) Resource leak: orig

$ fgrep -n orig ../BUILD/createrepo_c/src/misc.c
373: cleanup_file_fclose FILE *orig = NULL;
387: if ((orig = fopen(src, "rb")) == NULL) {
405: while ((readed = fread(buf, 1, BUFFER_SIZE, orig)) > 0) {
406: if (readed != BUFFER_SIZE && ferror(orig)) {

createrepo_c/src/misc.c:421]: (error) Resource leak: new

$ fgrep -n new ../BUILD/createrepo_c/src/misc.c
374: cleanup_file_fclose FILE *new = NULL;
396: if ((new = fopen(dst, "wb")) == NULL) {
412: if (fwrite(buf, 1, readed, new) != readed) {

Could you please publish the documentation somewhere? It could be either somewhere on Internet or in form of a software package. So far, it's not readable even in the source form so I have to build it locally from sources.

I'm reading hundreds of updateinfo.xml files in 10 threads in Python.

I end up with SIGSEGV, Segmentation fault.
Relevant part of backtrace:

#0  0x00007fffef7ef9f7 in get_datetime () from /usr/lib64/python2.7/site-packages/createrepo_c/_createrepo_c.so
#1  0x00007ffff7a5682e in getset_get () from /lib64/libpython2.7.so.1.0

It's not 100% reproducible, looks like it's caused by a race condition.
I'll try to get a reliable reproducer or more data.

I am using "createrepo_c --update --retain-old-md 4 ." and the files in repodata keeps growing after each run. Does --retain-old-md option work for anyone? Am I missing something?

Hi, while perusing the commit log of this repository one thing instantly struck me. The lack of actual commit messages.

Sure there's a one line (sometimes too long a line) summary but where's the rest? Not too easy to follow what's going on.

Here's what a good commit message should generally look like.
https://github.com/torvalds/subsurface/blob/master/README#L87

If you want more real-world examples of generally good commit messages, just browse the Linux Kernels log

Cheers,
Andrew

While Mageia was working on implementing usage of createrepo_c to regularly generate rpm-md data, it was discovered that it was much slower on compressing xz metadata than gzip. Looking through the code on compression, it doesn't appear that you're using multi-threaded compression.

As of xz 5.2.0, the multi-threaded API is now stable and can be used in production. The documentation for this was incorrect in 5.2.0 (indicating only decompression support) but that was fixed in 5.2.2.

You may want to implement threaded (de)compression for bzip2 and gzip too.

See the Mageia bug report for more information.

It appears that createrepo_c is filtering Requires based on whether the package in question also Provides the same capability. However, the with that is it is not taking into account the version associated with the Provides when filtering Requires. Thus, situations where a package provides an older version of the capability but requires a newer version leads to the capability being stripped from the Requires, which breaks the install.

This has occurred with the mutter package with GNOME 3.22 in Mageia Cauldron (development for Mageia 6).

Reference: https://bugs.mageia.org/show_bug.cgi?id=19509

Consider the latest Fedora compose which uses createrepo_c. Look at the comps.xml file. you'll see something like this:

<!DOCTYPE comps PUBLIC "-//Red Hat, Inc.//DTD Comps info//EN" "comps.dtd">

It would be more correct to use this one: https://pagure.io/fedora-comps/blob/master/f/comps.dtd

I've also written some about other options here: https://pulp.plan.io/issues/1786#note-4

To make things easier on people packaging createrepo_c, please make proper releases of createrepo_c like you do for librepo. It makes it much easier to manage from the packager's point of view, since we can point directly to a GitHub release URL for the tarball source.

It would be nice to document how are the parameters of createrepo_c.package_from_rpm used. E.g. that location_href is used to set the corresponding attribute of the package instance.

Please document which exceptions can be raised if filename does not point to a (readable) RPM package.

I would like to point out that an identifier like "__C_CREATEREPOLIB_CMD_PARSER_H__" does not fit to the expected naming convention of the C language standard.
Would you like to adjust your selection for unique names?

I just want to create a repository from files in a given repository. I don't need any customizations. It would be nice if there was a function that can do that (just like if I execute createrepo) so that I don't need to duplicate createrepo_c/examples/python/simple_createrepo.py. Please don't forget to document the exceptions that can be raised.

Is it true that createrepo_c is intended to replace createrepo? If yes, can you please document the repository format (the content of the directory and what purpose each file serves) so that we can use the same terms to document e.g. hawkey.Repo?
I mean something like http://createrepo.baseurl.org/ but ideally without the "FIXME" note :)
Or do you think that hawkey is rather the library that should define the format?

Certain types of corrupt XML files can result in memory corruption when loaded.
Specifically, this can happen if a package element is opened and XML parsing stops before it is closed, in other.xml (and probably in filelists.xml).

This affects createrepo_c when running with the --update argument but can also be demonstrated by cr.Metadata(use_single_chunk=True).locate_and_load_xml(...) from python.

Version: createrepo_c-0.7.4-1.fc20 (also confirmed in a3aaa03 )
Testcase: createrepo_c-crashbug.tar.gz (sha256: 9b8ffdb64b2359fb07e00dcbeaead68d167d8eecfd58e1531d5afd265a02a692)

$ curl -LO https://www.dropbox.com/s/xfzszf712ppyy8c/createrepo_c-crashbug.tar.gz
$ tar -xzf createrepo_c-crashbug.tar.gz 
$ ./createrepo_c-crashbug/run 
+ exec valgrind --tool=memcheck python ./crashbug.py
==1689== Memcheck, a memory error detector
==1689== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==1689== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info
==1689== Command: python ./crashbug.py
==1689== 

(process:1689): C_CREATEREPOLIB-CRITICAL **: cr_xml_parser_generic: parsing error 'badrepo/repodata/3edce8edbbffd8ccf7c569cc36e81c638b84d778348307c4dd20692269230510-other.xml.gz': no element found

(process:1689): C_CREATEREPOLIB-CRITICAL **: cr_metadata_load_xml: Error encountered while parsing
Metadata parsing failed (as expected).
Traceback (most recent call last):
  File "./crashbug.py", line 17, in <module>
    main()
  File "./crashbug.py", line 10, in main
    md.locate_and_load_xml(REPO_PATH)
createrepo_c.CreaterepoCError: Error encountered while parsing:other.xml parsing: Parse error 'badrepo/repodata/3edce8edbbffd8ccf7c569cc36e81c638b84d778348307c4dd20692269230510-other.xml.gz' at line: 16 (no element found)
==1689== Invalid read of size 8
==1689==    at 0x3E4B669FCE: g_string_chunk_free (in /usr/lib64/libglib-2.0.so.0.3800.2)
==1689==    by 0xBF8B55F: cr_metadata_free (in /usr/lib64/libcreaterepo_c.so.0.7.4)
==1689==    by 0xBD6BA51: ??? (in /usr/lib64/python2.7/site-packages/createrepo_c/_createrepo_cmodule.so)
==1689==    by 0x3D6286DB01: ??? (in /usr/lib64/libpython2.7.so.1.0)
==1689==    by 0x3D62904F2A: ??? (in /usr/lib64/libpython2.7.so.1.0)
==1689==    by 0x3D62904F3A: ??? (in /usr/lib64/libpython2.7.so.1.0)
==1689==    by 0x3D6287EA2E: ??? (in /usr/lib64/libpython2.7.so.1.0)
==1689==    by 0x3D628803EF: ??? (in /usr/lib64/libpython2.7.so.1.0)
==1689==    by 0x3D628828E7: PyDict_SetItemString (in /usr/lib64/libpython2.7.so.1.0)
==1689==    by 0x3D628F17A2: PyImport_Cleanup (in /usr/lib64/libpython2.7.so.1.0)
==1689==    by 0x3D628FD36D: Py_Finalize (in /usr/lib64/libpython2.7.so.1.0)
==1689==    by 0x3D6290E584: Py_Main (in /usr/lib64/libpython2.7.so.1.0)
==1689==  Address 0xbd31678 is 8 bytes inside a block of size 40 free'd
==1689==    at 0x4A07577: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==1689==    by 0x3E4B64EF7E: g_free (in /usr/lib64/libglib-2.0.so.0.3800.2)
==1689==    by 0xBF8FDED: cr_package_free (in /usr/lib64/libcreaterepo_c.so.0.7.4)
==1689==    by 0x3E4B638372: ??? (in /usr/lib64/libglib-2.0.so.0.3800.2)
==1689==    by 0x3E4B6390B0: g_hash_table_remove_all (in /usr/lib64/libglib-2.0.so.0.3800.2)
==1689==    by 0x3E4B63911D: g_hash_table_destroy (in /usr/lib64/libglib-2.0.so.0.3800.2)
==1689==    by 0xBF8B9C0: cr_metadata_load_xml (in /usr/lib64/libcreaterepo_c.so.0.7.4)
==1689==    by 0xBF8BCCB: cr_metadata_locate_and_load_xml (in /usr/lib64/libcreaterepo_c.so.0.7.4)
==1689==    by 0xBD6BFF3: ??? (in /usr/lib64/python2.7/site-packages/createrepo_c/_createrepo_cmodule.so)
==1689==    by 0x3D628E0BC3: PyEval_EvalFrameEx (in /usr/lib64/libpython2.7.so.1.0)
==1689==    by 0x3D628E097F: PyEval_EvalFrameEx (in /usr/lib64/libpython2.7.so.1.0)
==1689==    by 0x3D628E21DC: PyEval_EvalCodeEx (in /usr/lib64/libpython2.7.so.1.0)
==1689== 
==1689== Invalid read of size 8
==1689==    at 0x3E4B669FE0: g_string_chunk_free (in /usr/lib64/libglib-2.0.so.0.3800.2)
==1689==    by 0xBF8B55F: cr_metadata_free (in /usr/lib64/libcreaterepo_c.so.0.7.4)
==1689==    by 0xBD6BA51: ??? (in /usr/lib64/python2.7/site-packages/createrepo_c/_createrepo_cmodule.so)
==1689==    by 0x3D6286DB01: ??? (in /usr/lib64/libpython2.7.so.1.0)
==1689==    by 0x3D62904F2A: ??? (in /usr/lib64/libpython2.7.so.1.0)
==1689==    by 0x3D62904F3A: ??? (in /usr/lib64/libpython2.7.so.1.0)
==1689==    by 0x3D6287EA2E: ??? (in /usr/lib64/libpython2.7.so.1.0)
==1689==    by 0x3D628803EF: ??? (in /usr/lib64/libpython2.7.so.1.0)
==1689==    by 0x3D628828E7: PyDict_SetItemString (in /usr/lib64/libpython2.7.so.1.0)
==1689==    by 0x3D628F17A2: PyImport_Cleanup (in /usr/lib64/libpython2.7.so.1.0)
==1689==    by 0x3D628FD36D: Py_Finalize (in /usr/lib64/libpython2.7.so.1.0)
==1689==    by 0x3D6290E584: Py_Main (in /usr/lib64/libpython2.7.so.1.0)
==1689==  Address 0xbd60f60 is 0 bytes inside a block of size 16 free'd
==1689==    at 0x4A07577: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==1689==    by 0x3E4B64EF7E: g_free (in /usr/lib64/libglib-2.0.so.0.3800.2)
==1689==    by 0x3E4B665A64: g_slice_free_chain_with_offset (in /usr/lib64/libglib-2.0.so.0.3800.2)
==1689==    by 0x3E4B669FF9: g_string_chunk_free (in /usr/lib64/libglib-2.0.so.0.3800.2)
==1689==    by 0xBF8FDED: cr_package_free (in /usr/lib64/libcreaterepo_c.so.0.7.4)
==1689==    by 0x3E4B638372: ??? (in /usr/lib64/libglib-2.0.so.0.3800.2)
==1689==    by 0x3E4B6390B0: g_hash_table_remove_all (in /usr/lib64/libglib-2.0.so.0.3800.2)
==1689==    by 0x3E4B63911D: g_hash_table_destroy (in /usr/lib64/libglib-2.0.so.0.3800.2)
==1689==    by 0xBF8B9C0: cr_metadata_load_xml (in /usr/lib64/libcreaterepo_c.so.0.7.4)
==1689==    by 0xBF8BCCB: cr_metadata_locate_and_load_xml (in /usr/lib64/libcreaterepo_c.so.0.7.4)
==1689==    by 0xBD6BFF3: ??? (in /usr/lib64/python2.7/site-packages/createrepo_c/_createrepo_cmodule.so)
==1689==    by 0x3D628E0BC3: PyEval_EvalFrameEx (in /usr/lib64/libpython2.7.so.1.0)
==1689== 
(... many more)

A theory about the root cause:

When running in single chunk mode, there is one GStringChunk which belongs to the cr_Metadata. It's temporarily assigned/unassigned to/from cr_Package objects in newpkgcb/pkgcb in load_metadata.c.

If XML parsing stops in the middle of a package element, pkgcb is not called for the last cr_Package, so the chunk remains assigned to that object.

The chunk is then freed twice, once when the hash table of packages is destroyed (end of cr_metadata_load_xml function) and again when the cr_Metadata object is destroyed.

The function "exit" does not belong to the list of async-signal-safe functions.
I guess that a different program design will be needed for your function "sigint_catcher".

Would it be reasonable to provide some default values of the createrepo_c.XmlFile.__init__ parameters? I mean at least for contentstat but maybe also for compression_type?

I'd like to find out if the schema for repomd.xml can be modified to include an additional entry in:

<!ELEMENT data (location | checksum | timestamp | open-checksum | open-size | size | database_version)+>
seen here:
https://github.com/rpm-software-management/yum/blob/master/docs/repomd.dtd

which could hold an additional MD5 checksum for the repo metadata files.

Would this cause any issues with existing clients if so, or would clients ignore "extraneous" elements that they're not using?

This is because it adds further items inside an assert which is compiled out.

The example createrepo_c/examples/python/simple_createrepo.py calls createrepo_c.RepomdRecord.fill with createrepo_c.SHA256. It would be nice if you could document this method parameter and explain why it is a good idea to call it. It seems that createrepo segfaults if the method is called without any argument.
Would it be possible to pass the checksum type to the constructor? It would save me few
letters and one variable name :) (filed a separate report #28)

It also seems that it may raise some exceptions. Could it be documented, please?

It would be nice if I could use:

with createrepo_c.XmlFile(filename, filetype, compression, None) as xmlfile:
    xmlfile.set_num_of_pkgs(len(packages))
    for package in packages:
        xmlfile.add_pkg(package)

instead of

xmlfile = createrepo_c.XmlFile(filename, filetype, compression, None)
try:
    ...
    xmlfile.set_num_of_pkgs(len(packages))
    for package in packages:
        xmlfile.add_pkg(package)
finally:
    xmlfile.close()

It is currently impossible to remove a record via the python bindings, since neither remove_record nor detach_record are exposed.

PR #64 fixes the direct issue that caused with duplicated records, but these functions should be exposed.

repodata is an ideal candidate for zopfli as it is compressed once and mirrored a lot. The compressed files are stream compatible with gzip and end users should only notice the files are themselves smaller.

Can an option be added to createrepo_c to utilize zopfli instead of gzip for .gz files.

https://github.com/google/zopfli
https://koji.fedoraproject.org/koji/packageinfo?packageID=16157

I am building createrepo_c with drpm but looks like there is some missing declarations:

[ 1%] Building C object src/CMakeFiles/libcreaterepo_c.dir/deltarpms.c.o
/home/edsiper/deps/createrepo_c/src/deltarpms.c: In function ‘cr_deltapackage_from_drpm_base’:
/home/edsiper/deps/createrepo_c/src/deltarpms.c:146: warning: passing argument 1 of ‘drpm_read’ from incompatible pointer type
/home/edsiper/deps/drpm/drpm.h:71: note: expected ‘struct drpm *’ but argument is of type ‘const char *’
/home/edsiper/deps/createrepo_c/src/deltarpms.c:146: warning: passing argument 2 of ‘drpm_read’ from incompatible pointer type
/home/edsiper/deps/drpm/drpm.h:71: note: expected ‘const char *’ but argument is of type ‘struct drpm *’
/home/edsiper/deps/createrepo_c/src/deltarpms.c:146: error: ‘EOK’ undeclared (first use in this function)
/home/edsiper/deps/createrepo_c/src/deltarpms.c:146: error: (Each undeclared identifier is reported only once
/home/edsiper/deps/createrepo_c/src/deltarpms.c:146: error: for each function it appears in.)
/home/edsiper/deps/createrepo_c/src/deltarpms.c:152: error: ‘DRPM_SOURCE_NEVR’ undeclared (first use in this function)
/home/edsiper/deps/createrepo_c/src/deltarpms.c:161: error: ‘DRPM_SEQUENCE’ undeclared (first use in this function)
/home/edsiper/deps/createrepo_c/src/deltarpms.c: In function ‘cr_deltarpms_scan_targetdir’:
/home/edsiper/deps/createrepo_c/src/deltarpms.c:617: warning: implicit declaration of function ‘g_queue_free_full’
/home/edsiper/deps/createrepo_c/src/deltarpms.c: In function ‘walk_drpmsdir’:
/home/edsiper/deps/createrepo_c/src/deltarpms.c:706: warning: implicit declaration of function ‘g_slist_free_full’
/home/edsiper/deps/createrepo_c/src/deltarpms.c: In function ‘cr_prestodelta_thread’:
/home/edsiper/deps/createrepo_c/src/deltarpms.c:781: warning: ignoring return value of ‘g_slist_append’, declared with attribute warn_unused_result
/home/edsiper/deps/createrepo_c/src/deltarpms.c: In function ‘cr_deltarpms_generate_prestodelta_file’:
/home/edsiper/deps/createrepo_c/src/deltarpms.c:865: warning: assignment discards qualifiers from pointer target type
make[2]: *** [src/CMakeFiles/libcreaterepo_c.dir/deltarpms.c.o] Error 1
make[1]: *** [src/CMakeFiles/libcreaterepo_c.dir/all] Error 2

any help is appreciated

Please add options for the CMake scripts to generate the man pages from source and the Python API documentation. For distributions that strongly prefer "full build from source", this is really important.

In some case createrepo is failing because it request a mirror on 443 whereas the given mirror only really support http 80.

What I would expect is that createrepo_c is agnostic about that, but instead it should default to http, unless explicitly requested.

http://koji.rpmfusion.org/kojifiles/work/tasks/3514/73514/mergerepos.log

Looks like the project is missing some linking on CMake:

Linking C shared library libcreaterepo_c.so
[ 54%] Built target libcreaterepo_c
[ 56%] Building C object src/CMakeFiles/createrepo_c.dir/createrepo_c.c.o
[ 57%] Building C object src/CMakeFiles/createrepo_c.dir/cmd_parser.c.o
Linking C executable createrepo_c
libcreaterepo_c.so.0.6.1: undefined reference to g_queue_free_full' libcreaterepo_c.so.0.6.1: undefined reference tog_slist_free_full'