Will it still be possible to read old discussion threads?
If no, I would like it if this one could be migrated (for the conclusions
reached in the thread):
https://github.com/pulp/community/discussions/73
Quirin (quba42)
From: pulp-dev-boun...@redhat.co
Just wanted to add a comment regarding the reason for the ULN version bump
below.
From: pulp-dev-boun...@redhat.com on behalf of
Daniel Alley
Sent: 11 May 2021 20:55
To: Grant Gainey
Cc: Pulp-dev
Subject: Re: [Pulp-dev] pulp_rpm and current backwards-compatib
Regarding "Should Katello use auto-publish/distribute feature?":
* I started working on this feature for pulp_deb yesterday, I do not yet
have any kind of ETA when it will be done.
Regarding the Docker migration fix:
* I added a comment to the PR here:
https://github.com/pulp/pulp-2to3
trike anyone as problematic?
How are other plugins handling cherry-picks (in general and for Katello in
particular)?
Kind regards,
Quirin Pamp (quba42)
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://listman.redhat.com/mailman/listinfo/pulp-dev
Hi,
it looks like there is now a commit on pulp_rpm that uses something named
"urlpath_sanitize" instead of urljoin.
This is causing a major clash with this PR:
https://github.com/pulp/pulp_rpm/pull/1896 which has replaced a lot of
urljoin's with os.path.join.
My problem is that since I am not
Recently it has been happening with some regularity that the main "test" CI
workflow for pulp_deb gets stuck indefinitely during the "Install" step.
See here for an example:
https://github.com/pulp/pulp_deb/runs/2136544386?check_suite_focus=true
I just wanted to ask if others have made similar o
documentation on
readthedocs (or replace it with a single URL to the new docs location).
If whoever has the relevant access rights to do this could do so, I would be
much obliged.
Kind regards,
Quirin Pamp (quba42)
___
Pulp-dev mailing list
Pulp-dev@redhat.com
The pulp_deb plugin currently makes use of md5, sha1, sha256, and sha512.
Using ALLOWED_CONTENT_CHECKSUMS to "prohibit" one or more of these checksum
types currently simply breaks the plugin.
This is one (of several) reasons why the pulp_deb CI tests are currently broken
against pulpcore master (
ainst the Django convention" a conscious choice, rather than an
historical accident)?
Looking forward to your insights,
Quirin Pamp (quba42)
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev
releases,
or if there is some immediate need.
A related question: When is the plugin_template given a tag? Whenever someone
feels like generating a new changelog for it?
Regards,
Quirin Pamp
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https
l) reason not to go ahead with this, or use a
different name than "main"?
Quirin Pamp (quba42)
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev
ps open an issue
for it).
Kind regards,
Quirin Pamp (quba42)
From: Ina Panova
Sent: 01 October 2020 15:00
To: Dennis Kliban
Cc: Quirin Pamp ; Pulp-dev
Subject: Re: [Pulp-dev] sphinx theme for docs.pulpproject.org
my preference number 1 would be making plugins
ion cycle, some more pointers/examples on how
to use this in practice would be good.) Is it just a matter of running the test
suite against each pulpcore version that I am declaring compatibility with?
Any thoughts and hints are appreciated!
Kind regards,
Quirin Pamp (quba42)
___
I don't have a strong opinion, but I feel like if we don't come up with
anything better we could just fall back to what the pulpcore docs are
currently using.
https://docs.pulpproject.org/pulpcore/
https://github.com/pulp/pulpcore/blob/d31eb22453cd2d56b43ed884ec193fa166cafe62/docs/conf.py#L116
"I'd encourage plugins to consider disabling merge by commit as well."
In order to evaluate this it would be great, if you could explain why this was
decided for pulpcore and pulp_file.
You have posted a lot of general information about the different merge type
(the "What?"), but not so much on
meeting.
I also get the feeling, continuing SigningService work isn't at the top of
anyone's To-Do list right now. We will see who blinks first.
From: Brian Bouterse
Sent: 16 September 2020 22:55
To: Quirin Pamp
Cc: pulp-dev@redhat.com
Subject: Re:
Since most of the core people I would like to see there have indicated to me
that 14:00 o'clock CEST would work for them, I think the time is fixed now.
From: Dennis Kliban
Sent: 23 July 2020 18:09
To: Quirin Pamp
Cc: pulp-dev@redhat.com
Subject: Re:
, 13:00 o'clock CET as a preliminary date, but this
will likely still change, since I have not yet checked with anyone's schedule.
Feel free to propose a different time, or amend the Agenda here:
[1] https://hackmd.io/kGjFFGtWTJSGuIDlVlgqZw
thanks,
Q
Hi,
However we decide to continue with the SigningService topic in the medium and
longrun, I wanted to have one more go at unblocking the following PR in the
short run:
https://github.com/pulp/pulpcore/pull/659
Currently, this PR issues a warning whenever the hash of a signing service
scri
Hi Everyone,
I would like to establish some process around routine maintenance of the
pulp_deb plugin.
I am writing the mailing list about it, both because I want to give anyone who
might be interested a chance to contribute, as well as because I hope to get
some answers from the community reg
e points up for me (either directly,
or by pointing me in the right direction), I could better contribute to design
discussions in the future.
thanks,
Quirin
____
From: Brian Bouterse
Sent: 10 June 2020 21:03:45
To: Quirin Pamp
Cc: Pulp-dev
Subject: Re: [Pulp-dev] S
Wednesday June 10th 11:00 EDT. If I am not mistaken that is 17:00 CET, which
works for me.
From: pulp-dev-boun...@redhat.com on behalf of
Brian Bouterse
Sent: 01 June 2020 17:42:17
To: Pulp-dev
Subject: Re: [Pulp-dev] Signing Service Meeting Schedule on #pulp-
Could you explain the reasoning for a 'public.key' file?
In the case of the AptReleaseSigningService we built for pulp_deb we saw zero
need for this file and consequently did not add it in.
(It would not be hard to add it just to satisfy the interface, it just would
not serve any useful purpos
major rework of its documentation, but I
would like to avoid having to do that twice in a row. ;-)
regards,
Quirin Pamp
From: pulp-dev-boun...@redhat.com on behalf of
Brian Bouterse
Sent: 01 May 2020 20:59:18
To: Fabricio Aguiar
Cc: Pulp-dev
Subject: Re
pulp-deb 2.3.0b1 (beta) has been released to https://pypi.org/project/pulp-deb/
today.
(I prepared, and Mathias Dellweg carried out the release, my thanks to him.)
This beta release is compatible with pulpcore 3.3 and contains SigningService
support and several bug fixes.
Change log is availab
I have grown used to always running the fixtures container locally in my
pulplift boxes using the pfixtures command (essential when working on new
fixtures).
This command could be made a bit more flexible (right now it always runs in the
foreground and always uses the latest container image fro
sufficient 😉)
Thanks,
Quirin Pamp
From: pulp-dev-boun...@redhat.com on behalf of
Ina Panova
Sent: 21 April 2020 14:07:13
To: Daniel Alley
Cc: Pulp-dev
Subject: Re: [Pulp-dev] the "relative path" problem
Daniel,
how about setting up a meeting and brai
27 matches
Mail list logo