IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
We are, in fact, interested in
- fresh packages that were never rebuild;
- old packages that were rebuild recently, but are still old.
This change makes sure that such packages are included
into update_days report.
Instead of falling back to alphabetical order when
cycle is detected, we try to break it and form
the topological order again. Even if cycles are
broken at the wrong edge, this order might still
be more useful.
All the cycles found are included into the report.
... if possible. If not, summary is sorted alphabetically
and the first cycle found is reported to logs.
Dependencies for sorting use very strong model: A should
be rebuild before B if any packages built from A are
in the build chroot for B. Of course, our rudimentary
implementation of chroot_for does not mimic real
apt packages selecting logic, so it gives us just an
approximation, but hopefully a useful one.
Instead of putting all the dependencies in one list,
print build requires first, then '::', then extra
requires that are needed for installation only
(but not building).
- support for multiple arguments
- allow an argument to be in '.src.rpm' form
(also, the version and release are ignored for now)
- mark any additional sources which were not explicitly
asked for in summary.
This is the initial version of cross-repository report
that tries to give an approximate answer to the question:
"What other packages we should build with this one, and
why?"
We try to model repository as collection of source and
binary packages with their dependencies, and do some
stuff with it.
The initial version can calculate a list of unmets.
Previously, if the package in 'new' repo had larger version,
it was still called ORANGE. It was "optimization" from
the times when we had only sisyphus_mipsel, and never
packaged newer versions before the main repo. But for
p9_mipsel that's not true, as well as when comparing
p9_mipsel and sisyphus_mipsel, which we also would
like to do.
For now, we just load src/pkglists and build a simple
report on what packages you have to have in order
to satisfy SRPM's build requires. Everything is
very approxymate, of course.
... based on the file path.
Sometimes info.json is moved before the state
is set to DONE. we need to fix this in girar, but for now
we opt for a simpler workaround.
... to get all the ENVRs of the packages it has.
Now comparing different arches of the same repo
is not important, and Sisyphus deperecated
source pkglists, so we can use the official
information source.
Previously, BY_NAME did not include packages that were
absent from both repositories. This meant that some functions
like `gspi` ignored them, which is inconvenient because
it does not show packages that were never built (like new
kernel flavors) or already deleted.
This commit addresses this in the following way:
- colorize.colorize() now takes additional argument,
an explicit list of package names to colorize
- for interactive console, this list is formed from
both repositories, AND all the package names found
in PACKAGE_TASKS.
Sometimes, when lists are updated while we are
reading them, we get 0 results, and all our
reports become very confusing. This change
adds a check to raise an exception in this case.
This function displays subtasks of the tasks
that would update packages in the target repo.
It is especially useful for determining why
the particular task gets into next_tasks(...)
output.
Implementing it nicely required a bit of refactoring
to factor out certain parts of colorizing
and display mech.
