- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jan 8 2023
Oct 19 2022
May 11 2022
May 10 2022
Considering this done, closing.
May 9 2022
May 3 2022
Yes; and they should be already supported in SWH (if some places don't, then it's a bug)
Apr 27 2022
Feb 22 2022
Feb 19 2022
Run finished [1].
Totalling 980k bzr origins on launchpad [2]
Feb 18 2022
After ^, listing triggered again, and listing still ongoing, current status [1]
Feb 17 2022
Feb 16 2022
Feb 15 2022
New lister did its work, 74 new origins got seen [1] [2].
Feb 14 2022
@Alphare fixed the sourceforge lister to list correctly bzr origins.
Tagged a v2.6.4 with that fix in the intent to deploy this on staging.
Feb 11 2022
And deployed.
Next step: Actually feeding them some bzr origins.
We'll need to discuss some more with @Alphare.
Of course, the build was ok, but not the actual install [1]
Another build release ongoing to fix that... [2]
After some more fight and backporting dependencies [1] [2]. The build is now happy on
stable as well [3].
Feb 10 2022
Previous one fixed.
pypi-upload job failed for some reason.
Fixed.
Yes, thanks for the heads up.
D7130 has been committed, so a new version of the loader for faster ingestion will need to be released.
Feb 9 2022
- Prepare the necessary debian metadata files to allow CI package build [1]
Here we go, first release is up. [1]
Repository configured correctly regarding the ci.
But the hook was missing on the repository.
Fixed [1].
Let's do the first release.
Feb 8 2022
loader-bzr run in docker \o/:
- Make it run within docker
Feb 7 2022
We got those bzr origins currently listed in staging (and prod) infra [1].
Do they sound good enough as dataset?
Jan 28 2022
I suggested Co-Authored-By because it is a de-facto standard in Git now thanks to GitHub, so we already have many revisions using this "format" (no releases as far as I know, though).
Jan 27 2022
Then let's just go for it (insert here ref. to upcoming separate task :-)).
In T3887#77951, @zack wrote:Do you foresee any issue in adding extra_headers to releases as well, other than "someone should do it"?
In T3887#77949, @olasd wrote:Now that I've written it out loud, of course, Releases don't have extra_headers so the package loaders can't make use of this workaround/hack for now.
Now that I've written it out loud, of course, Releases don't have extra_headers so the package loaders can't make use of this workaround/hack for now.
From merged tasks, this would also be useful for some package loaders, e.g. npm, that support multiple authors in their packaging metadata.
Practically, we could be storing the metadata on additional authors *now* in the extra_headers field (make them a bunch of (b'author', b'XXX <yyy@zzz.ttt>') entries). Of course, that doesn't solve the question of presenting the information.
Is this information fully intrinsic, or can it be modified without the revision id changing ?
That works for me
Should we have an ad-hoc coding of sorts?
Jan 26 2022
It seems like the expected type of Tuple[Tuple[bytes, bytes], ...] does not offer any nesting opportunities. Should we have an ad-hoc coding of sorts? Am I just missing something?
extra_headers looks like the best way to do this.