Hi,
A little late for the party , I decide publish my helper_scripts on a
github repo, maybe all this will be supersede by Packit
https://github.com/sergiomb2/herlper_scripts
Usage :
fedpkg clone foo-package
cd foo-packge
~/bin/update_from_bugzilla.sh id_bug stage_number
echo "stage 0:
On Tue, 2023-06-20 at 21:01 -0600, Orion Poplawski wrote:
>
> You're addition of git pull is a good thing.
It's based on unfortunate experience. :D Using ; not && (as some others
suggested) is bad, though, I'll have to change that (would save me some
panicked ctrl-c'ing). I'm just somehow used to
On 6/18/23 04:28, Adam Williamson wrote:
On Sun, 2023-06-18 at 09:16 +, Mattia Verga via devel wrote:
For the 99% of packages I maintain I usually perform the same workflow
when updating them:
1. Update spec and source in Rawhide
2. commit and push
3. fedpkg build
4. fedpkg switch-branch f*
On 19-06-2023 12:51, Miroslav Suchý wrote:
Sounds like these tools are worth mentioning in the docs, seeing how
many people face the same challenge.
We (I am part of Packit team) plan to do more noise about it later.
Especially this feature - we have finished it in January and asked few
peopl
On Mon, Jun 19, 2023 13:02:45 +0200, Vít Ondruch wrote:
>
> Dne 19. 06. 23 v 11:55 Ankur Sinha napsal(a):
>
> >
> > We're discussing a different topic now.
>
>
> Sorry but we don't. The thread started with: "For the 99% of packages I
> maintain I usually perform the same workflow
> when updati
Dne 19. 06. 23 v 11:55 Ankur Sinha napsal(a):
On Mon, Jun 19, 2023 11:22:35 +0200, Vít Ondruch wrote:
Right, not pushing to all branches is in line with official guidelines:
https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#stable-releases
It's more nuanced than "don't push updates t
Dne 19. 06. 23 v 11:30 Sandro napsal(a):
2) Even better is Packit
https://packit.dev/
You have many ways to use it. My favorite way is to use pull-from-upstream
https://packit.dev/posts/pull-from-upstream/
You just make sure you have record in https://release-monitoring.org/ and then pu
On Mon, Jun 19, 2023 08:28:23 +0200, Vitaly Zaitsev via devel wrote:
> On 18/06/2023 17:42, Ankur Sinha wrote:
> > I threw all the commands into a script with some optional arguments:
>
> Maybe this script can be added to fedora-packager?
Sure, if folks find it useful enough. In the meantime, I a
On Mon, Jun 19, 2023 11:22:35 +0200, Vít Ondruch wrote:
> Right, not pushing to all branches is in line with official guidelines:
>
> https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#stable-releases
It's more nuanced than "don't push updates to all branches" though:
".. we should avoid
On 19-06-2023 11:04, Miroslav Suchý wrote:
Dne 18. 06. 23 v 11:16 Mattia Verga via devel napsal(a):
This is quite boring and time wasting... is there a more efficient way
to use my packaging time? Do you think fedpkg can be enhanced to have a
single command which makes 4-5-6 to all specified bra
On Mon, Jun 19, 2023 11:04:16 +0200, Miroslav Suchý wrote:
>
> 2) Even better is Packit
>
> https://packit.dev/
>
> You have many ways to use it. My favorite way is to use pull-from-upstream
>
> https://packit.dev/posts/pull-from-upstream/
>
> You just make sure you have record in http
Right, not pushing to all branches is in line with official guidelines:
https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#stable-releases
Especially I don't like my packages being FTBFS due to other packagers
pushing their updates everywhere. If there was at least included
mass-prebui
On Mon, Jun 19, 2023 08:46:47 -, Michael J Gruber wrote:
> > On Sun, Jun 18, 2023 at 09:16:28AM +, Mattia Verga via devel wrote:
> >
> > So one alternative is *not* to push the change to all branches.
> >
> > Unless it's really necessary, such as fixing an essential bug, I tend
> > to lea
On Mon, Jun 19, 2023 at 08:46:47AM -, Michael J Gruber wrote:
> > On Sun, Jun 18, 2023 at 09:16:28AM +, Mattia Verga via devel wrote:
> > (Also note 'fedpkg clone -B' option to use a separate subdirectory for
> > each branch, much more intuitive IMHO.)
>
> That creates a bunch of unrelated
Dne 18. 06. 23 v 11:16 Mattia Verga via devel napsal(a):
This is quite boring and time wasting... is there a more efficient way
to use my packaging time? Do you think fedpkg can be enhanced to have a
single command which makes 4-5-6 to all specified branches?
I know several ways:
1) Tito
ht
> On Sun, Jun 18, 2023 at 09:16:28AM +, Mattia Verga via devel wrote:
>
> So one alternative is *not* to push the change to all branches.
>
> Unless it's really necessary, such as fixing an essential bug, I tend
> to leave older Fedora branches on a stable release, to reduce churn
Exactly. B
On Sun, Jun 18, 2023 at 09:16:28AM +, Mattia Verga via devel wrote:
> For the 99% of packages I maintain I usually perform the same workflow
> when updating them:
>
> 1. Update spec and source in Rawhide
> 2. commit and push
> 3. fedpkg build
> 4. fedpkg switch-branch f*
> 5. git merge rawhid
On 19/06/2023 08:36, Mattia Verga via devel wrote:
I only need to find how to pass branch names to the alias, instead of
hardcoding them. From a quick search I need to create a function in
.bashrc rather than an alias.
Add to ~/.bashrc:
function fpr {
for i in f$(rpm -E %fedora) f$(($(rpm
Il 19/06/23 08:26, Vitaly Zaitsev via devel ha scritto:
> On 18/06/2023 14:51, Sandro wrote:
>> Aren't you missing the 'git push' (or 'fedpkg push')? IIRC, your 'fpb'
>> alias would fail since no changes have been pushed to dist-git for koji
>> to base a build on.
> Good catch. Thanks:
>
> alias fp
On 18/06/2023 17:42, Ankur Sinha wrote:
I threw all the commands into a script with some optional arguments:
Maybe this script can be added to fedora-packager?
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lis
On 18/06/2023 14:51, Sandro wrote:
Aren't you missing the 'git push' (or 'fedpkg push')? IIRC, your 'fpb'
alias would fail since no changes have been pushed to dist-git for koji
to base a build on.
Good catch. Thanks:
alias fpm="fedpkg switch-branch f38 && git merge rawhide && fedpkg
switch-
On Sun, Jun 18, 2023 at 5:17 AM Mattia Verga via devel
wrote:
>
> For the 99% of packages I maintain I usually perform the same workflow
> when updating them:
>
> 1. Update spec and source in Rawhide
> 2. commit and push
> 3. fedpkg build
> 4. fedpkg switch-branch f*
> 5. git merge rawhide
> 6. pu
On Sun, Jun 18, 2023 14:51:01 +0200, Sandro wrote:
> On 18-06-2023 14:16, Vitaly Zaitsev via devel wrote:
> > On 18/06/2023 11:16, Mattia Verga via devel wrote:
> > > This is quite boring and time wasting... is there a more efficient way
> > > to use my packaging time? Do you think fedpkg can be en
On 18-06-2023 14:16, Vitaly Zaitsev via devel wrote:
On 18/06/2023 11:16, Mattia Verga via devel wrote:
This is quite boring and time wasting... is there a more efficient way
to use my packaging time? Do you think fedpkg can be enhanced to have a
single command which makes 4-5-6 to all specified
On 18/06/2023 11:16, Mattia Verga via devel wrote:
This is quite boring and time wasting... is there a more efficient way
to use my packaging time? Do you think fedpkg can be enhanced to have a
single command which makes 4-5-6 to all specified branches?
Add to your ~/.bashrc the following:
ali
On Sun, 2023-06-18 at 09:16 +, Mattia Verga via devel wrote:
> For the 99% of packages I maintain I usually perform the same workflow
> when updating them:
>
> 1. Update spec and source in Rawhide
> 2. commit and push
> 3. fedpkg build
> 4. fedpkg switch-branch f*
> 5. git merge rawhide
> 6.
On 18-06-2023 11:16, Mattia Verga via devel wrote:
And repeat 4-5-6 for every f*/epel* branches where I want to push the
update.
That drill sounds familiar. ;)
If you look at he output of 'fedpkg build --help', there seems to be an
option to submit koji builds for multiple targets at once.
For the 99% of packages I maintain I usually perform the same workflow
when updating them:
1. Update spec and source in Rawhide
2. commit and push
3. fedpkg build
4. fedpkg switch-branch f*
5. git merge rawhide
6. push and fedpkg build
And repeat 4-5-6 for every f*/epel* branches where I want to
28 matches
Mail list logo
