Re: libravatar is in fedorainfracloud!

[Michal Novotny]

On Tue, Mar 5, 2019 at 6:06 AM Michal Schorm  wrote:
>
> This is what confused me:
>   My profile is names after my email address.
>   So I entirely ignored the button "add new email address", because I
> thought it must be obvious for the service.

Ah, right. Glad it works now!

>
> Works fine, thanks for the clarification!
>
> For the second part:
> seems fixed now. It was 100% reproducible for me by uploading jpeg
> (the exact same that I had already uploaded once). But I don't see the
> ERR 500 anymore.
> Also new error message "Invalid Format" has just been introduced,
> which covers that.

Cool, that's probably work of Oliver Falk :).

>
> --
>
> Michal Schorm
> Software Engineer
> Core Services - Databases Team
> Red Hat
>
> --
>
> On Tue, Mar 5, 2019 at 5:41 AM Michal Novotny  wrote:
> >
> > On Mon, Mar 4, 2019 at 4:26 PM Michal Schorm  wrote:
> > >
> > > Any idea how to use it?
> > >
> > > The: https://src.fedoraproject.org/settings#nav-basic-tab
> > > has an option to change the avatar.
> > > That will redirect me to: https://www.libravatar.org/account/login/
> > >
> > > I have an image uploaded in: https://www.libravatar.org/accounts/profile/
> > >
> > > But I found no way to somehow "apply" the image, or propagate it to
> > > the fedoraproject.org and use that one instead the generated ...
> > > something.
> >
> > Hello MIchal,
> >
> > in your profile at src.fp.o, there should be a default email address set
> > in "Email addresses" section.
> >
> > I checked that this is the email address that src.fp.o displays avatars
> > for.
> >
> > In libravatar, in your profile you should have that default email address
> > confirmed. Under "You have the following confirmed identities:".
> >
> > If you have that, you should be able to edit identity by clicking
> > on edit button in top-left corner. Then you should be able to
> > select your avatar from the images you have uploaded.
> >
> > >
> > > --
> > >
> > > Btw I still get "Server Error 500" on
> > > https://www.libravatar.org/accounts/upload_export/
> >
> > I have tried to upload a xml.gz file i have from previous
> > export from original libravatar.org and it worked. I got 500
> > only when I tried to upload e.g. a txt file. Could that be
> > the case? I reported the issue here
> > https://git.linux-kernel.at/oliver/ivatar/issues/53
> > so we can solve it there properly.
> >
> > Thanks for the report!
> > clime
> >
> > >
> > > --
> > > Michal Schorm
> > > --
> > > ___
> > > devel mailing list -- devel@lists.fedoraproject.org
> > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives: 
> > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: libravatar is in fedorainfracloud!

[Michal Novotny]

On Mon, Mar 4, 2019 at 4:26 PM Michal Schorm  wrote:
>
> Any idea how to use it?
>
> The: https://src.fedoraproject.org/settings#nav-basic-tab
> has an option to change the avatar.
> That will redirect me to: https://www.libravatar.org/account/login/
>
> I have an image uploaded in: https://www.libravatar.org/accounts/profile/
>
> But I found no way to somehow "apply" the image, or propagate it to
> the fedoraproject.org and use that one instead the generated ...
> something.

Hello MIchal,

in your profile at src.fp.o, there should be a default email address set
in "Email addresses" section.

I checked that this is the email address that src.fp.o displays avatars
for.

In libravatar, in your profile you should have that default email address
confirmed. Under "You have the following confirmed identities:".

If you have that, you should be able to edit identity by clicking
on edit button in top-left corner. Then you should be able to
select your avatar from the images you have uploaded.

>
> --
>
> Btw I still get "Server Error 500" on
> https://www.libravatar.org/accounts/upload_export/

I have tried to upload a xml.gz file i have from previous
export from original libravatar.org and it worked. I got 500
only when I tried to upload e.g. a txt file. Could that be
the case? I reported the issue here
https://git.linux-kernel.at/oliver/ivatar/issues/53
so we can solve it there properly.

Thanks for the report!
clime

>
> --
> Michal Schorm
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: libravatar is in fedorainfracloud!

[Michal Novotny]

On Thu, Feb 21, 2019 at 2:46 PM Tom Hughes  wrote:
>
> On 21/02/2019 13:41, Michal Novotny wrote:
>
> > I am not sure why http://libravatar.org to https://www.libravatar.org
> > redirect is bad. Can you, please, explain?
>
> The reason for saying it should redirect with www first
> and then to www after that if you want is to ensure that
> libravatar.org is visited over https without a prefix so
> that HSTS is recorded for all subdomains.

Great explanation, thanks. It should be fixed now.

>
> It's not essential if you only have a single name anyway
> but if you're doing includeSubdomains then it may be, and
> it is required for preload:
>
> https://hstspreload.org/?domain=libravatar.org
>
> Tom
>
> --
> Tom Hughes (t...@compton.nu)
> http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: libravatar is in fedorainfracloud!

[Michal Novotny]

On Thu, Feb 21, 2019 at 12:51 PM Till Maas  wrote:
>
> On Thu, Feb 21, 2019 at 09:40:16AM +0100, Michal Novotny wrote:
>
> > We, as a libravatar group, are very happy that Fedora Infra provided
> > us with the needed
> > hardware. We will keep the service running by our own effort.
>
> What is the right place report errors in the web server configuration
> regarding the Strict Transport Security HTTP header? There are two
> issues:
>
> - it does not contain includeSubDomains
> - http://libravatar.org odes not redirect directly to
>   https://libravatar.org but to the www subdomain instead.

Till, thank you for checking it! That's very valuable to us
and to me as well.

I've added IncludeSubDomains directive to HSTS declarations.
Can you take a look?

I am not sure why http://libravatar.org to https://www.libravatar.org
redirect is bad. Can you, please, explain?

Thank you
clime


>
> Kind regards
> Till
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: libravatar is in fedorainfracloud!

[Michal Novotny]

On Wed, Feb 20, 2019 at 8:27 PM John Harris  wrote:
>
> On Wednesday, February 20, 2019 5:49:13 AM EST Stephen John Smoogen wrote:
> > On Wed, 20 Feb 2019 at 00:07, John Harris  wrote:
> >
> > >
> > >
> > > On Tuesday, February 19, 2019 11:46:16 PM EST Michal Novotny wrote:
> > >
> > > > Hello!
> > > >
> > > >
> > > >
> > > > maybe you know that around April 2018, there was an announcement that
> > > > libravatar service (a service for serving user avatars) is shutting
> >
> >
> >
> > > Awesome! I'm glad we won't be losing libravatar, and I couldn't be
> > > happier
> > > that it's supported by Fedora's Infra.

John, thank you for the kind words!

We, as a libravatar group, are very happy that Fedora Infra provided
us with the needed
hardware. We will keep the service running by our own effort.

clime

> > >
> > >
> >
> >
> > I would like to clarify this as quickly as possible. Fedora
> > Infrastructure's support is only to give out hardware resources to the
> > this project. We do not have any fixing abilities other than rebooting
> > the server if it gets stuck. People having problems like libravatars'
> > avatars or login problems etc will need to contact the libravatar
> > organization versus #fedora-admin or the Fedora Infrastructure ticket
> > system.
> >
> >
> > --
> > Stephen J Smoogen.
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
> Haha, I could definitely see some confusion coming from that. Sorry for my
> wording.
>
> --
> John M. Harris, Jr. 
> Splentity
> https://splentity.com/___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

libravatar is in fedorainfracloud!

[Michal Novotny]

Hello!

maybe you know that around April 2018, there was an announcement that
libravatar service (a service for serving user avatars) is shutting
down: 
https://blog.libravatar.org/posts/Libravatar.org_is_shutting_down_on_2018-09-01/

This raised a big wave of interest in the service and in keeping it
alive because libravatar was here for quite a long time and used by
many parties including Pagure, Mozilla Firefox, or Linux kernel. A
group of people formed with the goal to port libravatar to a new
platform and new servers and
https://blog.libravatar.org/posts/Libravatar.org_is_not_going_away/
was published. Then the work on saving libravatar had begun...

And now, it is finally done! Yesterday at 17pm UTC, Francois Marier
flipped the DNS switch to point www.libravatar.org to the new server
and completely new, modern implementation placed in our Fedora cloud!
\o/ Check it out here: www.libravatar.org

I think it's quite a nice message of how well people in Open Source
and Free Software can cooperate and how they can make something
significant happen. I would like to say thank you to them and in
particular to:

Oliver Falk who rewrote libravatar from scratch
(https://git.linux-kernel.at/oliver/ivatar)

Francois Marier who wrote and maintained the original libravatar and
who was helping us all the time with the migration

Tristan Le Guern who was testing the new implementation and provided
great insights

Niklas Poslovski who themed new libravatar

Lars Kruse who lead our IRC meetings and setup our @libravatar.org
email addresses

Me who setup the new servers in Fedora Infra Cloud and did some
testing of the new implementation too

I would also like to thank the Fedora community and the Infra team for
providing us with the space in the cloud for the new service.

So yeah, if your avatars are not served properly, you know whom to
blame :). You can get in touch with us on #libravatar Freenode
channel. Through https://git.linux-kernel.at/oliver/ivatar bugtracker
or by writing to libravatar-f...@lists.launchpad.net mailing list.

Enjoy
clime
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Modularity implementation with rpm DistTag

[Michal Novotny]

Hello Petr,

> So, first, I'd like to thank you for taking the time to think
> about this.  It's certainly interesting and tries to solve similar
> problems from a completely different angle.
>
> Your proposal focuses on distribution packages rather than on
> independent applications.  I'd argue it introduces even more
> packaging complexity (all packages would need to be modified to
> depend on specific "streams" of other packages) than grouping
> unmodified packages into modules.

But if you want to provide multiple major versions of one software officially,
the additional complexity to handle availability of those different versions
in an ecosystem will always be there. I don't think anything can be done
about that :(.

But I also doubt that modularity, as it is, has a cure for that. What happens
if you install an rpm from a module for which the rest of the ecosystem
is not prepared? Meaning that it is too new and other standard available
rpms have it as an unqualified dependency?

And what happens if you introduce a module for which the rest of
the modules is not prepared? Containers is not an answer but an
excuse.

I think it is simply a fact that if you want to provide multiple versions
of the same software for a single system, you need to put some
work into more explicit Requires and BuildRequires when needed.

It can be a coordinated process though that would include
pull requests for packages that use the package for which a new
stream is being introduced. Also, it depends if there is a demand
to do that at all. What I tried to propose makes it possible in
a simple manner but it doesn't mean it needs to be done.

> I also worry that with such a
> fine-grained parallel availability, there would be very few
> possible combinations of packages that could be effectively
> installed on a single system.  Not to mention QA efforts.

Again, this imho comes from the fact that we are trying to
provide parallel availability in the first place. If we weren't,
then there wouldn't be any additional complexity.

Nevertheless, I don't see a problem in keeping the same "ground"
as we keep now for each Fedora release, which is all compatible,
while also providing something optional above that, which might
be less compatible (hopefully it is not but might be). Even this
has an added value for users given that they are able maintain
the ground if they want to.

In my proposal, maintaining the ground means using the implicit installs
($ sudo dnf install git) or explicit ones but only those that use the lowest
available streams for a periodical Fedora release. For a periodical release,
we can do it so that the lowest available streams are at the same time the
lowest compatible ones and they hence form a good "ground" from
which a user can optionally go up. We provide the ground already,
in fact. But we don't provide something on top of that.

>
> --
>
> That aside, a couple points touching some aspects of your proposal
> that you might interesting:
>
> * DistTag isn't actually unused.  The current modularity
>   implementation uses it to label MBS-procuded RPMs.  The
>   tag is also used by other distributions and we're currently
>   introducing a new header to avoid the conflict.
>   https://pagure.io/modularity/issue/113

Well, some other tag than DistTag can be used for specifying
the stream/branch name. I wanted to propose something that
already exists but is unused at least in Fedora (non-modular).

>
> * Soon, users will be able to choose whether they follow the
>   defaults for each individual module or stay on the stream they
>   initially picked/enabled.
>   https://pagure.io/modularity/issue/108
>
> * We do not compare stream names in any way, they're just strings.

Yes, the ordering in my proposal is there to make installation user-friendly
so that users don't need to specify explicit versions every time and at the
same time so that it can be made clear what will be installed by default.

I would like if a future/imagined interface of our update system made the
ordering clear graphically for packagers to be able to navigate quickly.

Of course, one can always also do:

$  git branch | LC_ALL=en_US.UTF-8 sort

locally to see how the branches sort.

>   Streams don't have to be just major versions of upstream
>   software, they can indeed be anything the packagers want them to
>   be -- experimental builds, builds with different compiler flags,
>   builds with or without specific dependencies, and so on.

Yes, that's possible in my proposal too. I would argue that the main
use of streams will be separating major versions from each other.
Even minor ones can be separated if it is useful.

Other uses that involve twiddling with compiler flags or deps are possible too
given that the branch has a descriptive name. In this case, it would be good
to put the stream name into Release: tag too so that users will see also from
the rpm name that this is something extra. And also, there should be a standard
stream that 

Modularity implementation with rpm DistTag

[Michal Novotny]

Hello Fedora devels!

TL;DR: let's use rpm DistTag (DistTag, not the %dist macro) to denote
stream names

As we all know, modularity was created to provide
parallel-availability, that is providing the same package in its
different major versions from the same rpm repository.

The first question to ask is: "Why can't we just place two major
versions of a package alongside in the repo?"

That's possible but there are two problems with this. The first one is
that when you type

$ sudo dnf install git

dnf needs to determine what major version of git it should install.
User should be able to provide the information explicitly on
command-line, that is:

$ sudo dnf install git-1

or

$ sudo dnf install git-2

but doing that always for each package you install could be quite demanding.

The second problem is that once you have a git package of a certain
major version installed, you want to keep it on that version when
running an ordinary update command:

$ sudo dnf update git

dnf shouldn't be tempted to install git-2 (e.g. git-2.17.2-2) but it
should instead update git-1 on the system to the latest available
minor version if git-1 is the major version of git currently
installed.

Modularity solves the second problem by "streams" and the first
problem by a "default stream".

That's okay but I would argue there is much more simple solution to
those two problems, which reuses already known terminology and
technology.

What can be done is to put the information into which stream a package
belongs into the package spec file. That means, a packager will not
need to edit some additional files to enable parallel-availability.

I would argue that if every single package in Fedora used semantic
versioning, then we wouldn't need streams at all. dnf could simply
have a config option that would assure staying on the same major
version during updates unless told otherwise.

The concept of "stream" is only needed if there are upstreams/packages
that do not exactly conform to semantic versioning where change in the
first number means API breakage. I suspect there are quite a lot of
them still and maybe, in some cases, we would like to have streams
that stand for something else than a major version? E.g. devel that
stores always the latest upstream state and is updated automatically.

For that reason, I assume the concept of stream might be useful.

But the question is how to provide a stream name through rpm?

I was looking at
https://github.com/rpm-software-management/rpm/blob/master/lib/rpmtag.h
and found there is DistTag rpm tag that you can put into a spec file
and that seems to be unused these days.

According to what I have found in a comment in /usr/lib/rpm/macros on this tag:

#   Configurable distribution tag, same as DistTag: tag in a specfile.
#   The tag will be used to supply reliable information to tools like
#   rpmfind.
#
#%disttag

Fedora packages do not have it set:

E.g.:

$  rpm -q --queryformat '%{DISTTAG}\n' prunerepo-1.13-1.fc28.noarch.rpm
(none)

and I don't think we need to care that much about rpmfind at least as
far as DistTag is the concern.

So it could be used to provide a "stream" name. I mean we don't really
need to call it stream either. What we essentially want is to group
packages of the same name by their major version or in some case by a
descriptive string like "devel".

Once we have this grouping provided for dnf, we can add an option like:

updates_maintain_disttag=true/false

which will make dnf updates stable if true and if packagers keep their
DistTags set to package major versions.

Another thing is that DistTag value can be automatically derived from
DistGit branch name. Meaning that if you use arbitrary branching like
e.g. nodejs uses (https://src.fedoraproject.org/rpms/nodejs/branches)
where branch names correspond to major versions, then with some kind
of auto-generation in place you can be just-about done only by
creating a branch with a proper name.

Funny thing is that this would work even if used with distro branches
because in distro branches, packagers should not update majors per
packaging guidelines (only maybe for leaf nodes with FESCo exception
it might be possible) so even though such stream (e.g. f29) would be a
mix of many different packages, those packages would maintain the same
major version during the stream active existence.

The second problem was to make

$ sudo dnf update git

work if there are e.g. two DistTags ("streams") 1 and 2.

Do you pick git-1 from DistTag 1 or git-2 from DistTag 2?

I would leave the decision what version to pick on a dnf config
option, which could be e.g.:

default_disttag_select_strategy=lowest_compatible

where sorting of DistTags follows the rules used by sort linux command
in en_US.UTF-8 locale:

$ sort
0
1.1
devel
3
1.11

0
1.1
1.11
3
devel

This means git-1 in its highest minor version is picked but only if
its compatible with already installed packages in the system. If not
compatbile, git-2 (having the next lowest DistTag) 

Re: Fedora Lifecycles: imagine longer-term possibilities

[Michal Novotny]

On Tue, Nov 20, 2018 at 1:57 PM Michal Novotny  wrote:

> On Tue, Nov 20, 2018 at 12:43 PM Tomas Tomecek 
> wrote:
>
>> > * Matthew Miller:
>> >
>> >
>> > Make it cheap to maintain branches.  I expect that one what to achieve
>> > this would be to build directly out of Git, with synthesized release
>> > numbers and changelogs.  This way, you can apply a lot of fixes to
>> > multiple branches without encountering mandatory conflicts.
>>
>> We are aiming for something similar what you just described. I created
>> this wiki page to describe the work briefly:
>>
>> https://fedoraproject.org/wiki/CI/source-git
>>
>> The actualy work is happening here now:
>>
>> https://github.com/user-cont/source-git
>>
>> We would love to take development off dist-git (but keep dist-git!) and
>> move it to git repos with real source code which match upstream
>> repositories. In such repo you have branches which track respective Fedora
>> versions -- you can easily cherry pick fixes. We would validate every pull
>> request in such repo and stuff would get merged only when it passes
>> testing. Right now we are trying to write minimal code to make such thing
>> work, evaluate it and present at devconf.cz to get some more feedback.
>>
>> Hopefully we would utilize clime's work to help with changelogs and
>> release numbers: https://pagure.io/rpkg-util/pull-request/15
>
>
> So that would be cool if my work is actually used. I recommend looking at
> https://pagure.io/rpkg-util/blob/master/f/macros specifically if you
> could use that.
>
> I planned to open a PR for python-rpkg do enable this functionality in
> Fedora but I am being delayed by work on rpkg-3.0, which is yet another
> *pkg client.
>
> Anyway, if there is some interest in making this available in Fedora soon,
> I can happily do it first. Just kick (contact) me.
> To be clear, the macros can only do the second point from "What and why?"
> at https://github.com/user-cont/source-git.
>

The README was changed meawhile so the second point from here:
https://github.com/user-cont/source-git/blob/3f0875dcaa08a48562d19879cf53104bcac5cdd4/README.md


>
> As for Fabio's question below if this would imply mirroring upstream Git
> repos in our DistGit: If rpkg macros are employed (linked above), then
> both use-cases (mirroring and uploading tarballs) will be possible. It
> will depend on packager's decision for each individual package and you
> could switch between these two anytime. It would also actually mean that
> development stays on DistGit and is encouraged there.
>
> M.
>
>
>>
>>
>>
>> Tomas
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

[Michal Novotny]

On Tue, Nov 20, 2018 at 12:43 PM Tomas Tomecek  wrote:

> > * Matthew Miller:
> >
> >
> > Make it cheap to maintain branches.  I expect that one what to achieve
> > this would be to build directly out of Git, with synthesized release
> > numbers and changelogs.  This way, you can apply a lot of fixes to
> > multiple branches without encountering mandatory conflicts.
>
> We are aiming for something similar what you just described. I created
> this wiki page to describe the work briefly:
>
> https://fedoraproject.org/wiki/CI/source-git
>
> The actualy work is happening here now:
>
> https://github.com/user-cont/source-git
>
> We would love to take development off dist-git (but keep dist-git!) and
> move it to git repos with real source code which match upstream
> repositories. In such repo you have branches which track respective Fedora
> versions -- you can easily cherry pick fixes. We would validate every pull
> request in such repo and stuff would get merged only when it passes
> testing. Right now we are trying to write minimal code to make such thing
> work, evaluate it and present at devconf.cz to get some more feedback.
>
> Hopefully we would utilize clime's work to help with changelogs and
> release numbers: https://pagure.io/rpkg-util/pull-request/15


So that would be cool if my work is actually used. I recommend looking at
https://pagure.io/rpkg-util/blob/master/f/macros specifically if you could
use that.

I planned to open a PR for python-rpkg do enable this functionality in
Fedora but I am being delayed by work on rpkg-3.0, which is yet another
*pkg client.

Anyway, if there is some interest in making this available in Fedora soon,
I can happily do it first. Just kick (contact) me.
To be clear, the macros can only do the second point from "What and why?"
at https://github.com/user-cont/source-git.

As for Fabio's question below if this would imply mirroring upstream Git
repos in our DistGit: If rpkg macros are employed (linked above), then
both use-cases (mirroring and uploading tarballs) will be possible. It will
depend on packager's decision for each individual package and you
could switch between these two anytime. It would also actually mean that
development stays on DistGit and is encouraged there.

M.


>
>
>
> Tomas
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: how to detect Atomic Rawhide?

[Michal Novotny]

On Wed, Oct 17, 2018 at 9:18 AM Pavel Raiskup  wrote:
>
> On Tuesday, October 16, 2018 4:03:56 PM CEST Miroslav Suchý wrote:
> > Or should I do quick'n'dirty "if 'rawhide' in
> > os-release['REDHAT_BUGZILLA_PRODUCT_VERSION']" in our copr plugin?
>
> Or REDHAT_SUPPORT_PRODUCT_VERSION.
>
> I'd simply read one of those variables, or submit PR against
> 'fedora-release' package to add some new variable with clearer semantics.
> No other package seems to be able to do the clear cut at branching time.
>
> Note that dnf neither knows whether VERSION_ID=30 means rawhide nowadays
> ($releasever expands to 30), the only difference on Rawhide system is that
> fedora-repos-rawhide is installed && the repos enabled.  But one can have
> 'fedora-repos-rawhide' installed also on stable.

I'd like to suggest that on Rawhide, VERSION_ID=rawhide and VERSION=Rawhide,
which then makes distinction between rawhide and non-rawhide clear.

os-release specs
(https://www.freedesktop.org/software/systemd/man/os-release.html)
allow VERSION_ID to be a non-numeric string.

Rawhide is an actual Fedora version. It's a version of Fedora that provides
a continuous stream of packages and serves mainly development purposes
(nowadays?).

Additional (side) note:
Stuff like "Workstation Edition", "Server Edition" or "Atomic Host"
should probably
only go to VARIANT and VARIANT_ID because it's not a release code name like e.g.
"Beefy Miracle" was for Fedora 17.

We are overusing codename VERSION substring for things that are not codenames
but they are variants and a version.

clime (Michal Novotny)

M.

>
> Pavel
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Self Introduction

[Michal Novotny]

I cannot take your review right now but i just want to say: Welcome!

Michal

On Thu, Aug 23, 2018 at 10:11 AM Manas Mangaonkar 
wrote:

> Hello,
>
> My name is Manas,i am a Computer Engineering student at the University of
> Mumbai.
>
> i recently began packaging with my first package being this
> ,and
> would love to work on even more packages. I am wish to join the packager
> group,thus seeking sponsorship.
>
> You may find the bugzilla review request for my first package here
> .
>
> Learned about the fedora community effort during Google summer of
> code,joined the mailing list saw a issue open and began working on it. Have
> been using various tux distro's since a teen always wanted to
> contribute,have been self taught.  Learned the ropes of packaging using
> the irc fedora chat room.
>
> I am mostly interested in packaging and maintaining python packages as i
> use python a lot and would love to give back to the community.
>
> My Github 
>
> - Manas Mangaonkar
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/GSZFIHQTY6AEENZ3YEHXYEDSVMW7SAQI/
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

copr-frontend: fix for webhook secrets leakage

[Michal Novotny]

Hello,

there have been security problem fixed in copr-frontend today. Basically by
forking, you could get to webhook secrets of an original project being
forked. Also the integration page where you can insert pagure api token was
actually available under certain URL if you knew how this URL should be
structured. Both of these problems are now fixed. See full details here:
https://lists.fedoraproject.org/archives/list/copr-de...@lists.fedorahosted.org/thread/VOOOVQ4VOZIB4GKXZWSX7REWCX3WVTLN/

We will do full security audits now to prevent any future problems like
this.
Sorry for this trouble
Copr team
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org/message/JJ3T74WRH63AMZB6TS3S72KUME2IUT7H/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JJ3T74WRH63AMZB6TS3S72KUME2IUT7H/

copr-frontend: fix for webhook secrets leakage

[Michal Novotny]

Hello,

there have been security problem fixed in copr-frontend today. Basically by
forking, you could get to webhook secrets of an original project being
forked. Also the integration page where you can insert pagure api token was
actually available under certain URL if you knew how this URL should be
structured. Both of these problems are now fixed. See full details here:
https://lists.fedoraproject.org/archives/list/copr-de...@lists.fedorahosted.org/thread/VOOOVQ4VOZIB4GKXZWSX7REWCX3WVTLN/

We will do full security audits now to prevent any future problems like
this.
Sorry for this trouble
Copr team
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org/message/JJ3T74WRH63AMZB6TS3S72KUME2IUT7H/

Fedora Copr can now flag commits and pull requests from src.fp.o

[Michal Novotny]

Hello,

in addition to auto-rebuilding feature from Fedora DistGit (
src.fedoraproject.org), we have added possibility to flag commits and pull
requests after an auto-rebuild. This works not only with Fedora DistGit but
with any pagure instance (e.g. also
https://upstreamfirst.fedorainfracloud.org/ or just pagure.io). The setup
for your Copr project is just a few simple steps. See the documentation
here:

https://docs.pagure.org/copr.copr/user_documentation.html#pagure-integration

or you can just also follow instructions present in Settings->Integrations
in your Copr project. Everything needed is there as well.

Please, enjoy
Copr team
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org/message/RXJ43NPVLOG33XZUT3QMVBR5PZN6HQQ5/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/RXJ43NPVLOG33XZUT3QMVBR5PZN6HQQ5/

Fedora Copr can now flag commits and pull requests from src.fp.o

[Michal Novotny]

Hello,

in addition to auto-rebuilding feature from Fedora DistGit (
src.fedoraproject.org), we have added possibility to flag commits and pull
requests after an auto-rebuild. This works not only with Fedora DistGit but
with any pagure instance (e.g. also
https://upstreamfirst.fedorainfracloud.org/ or just pagure.io). The setup
for your Copr project is just a few simple steps. See the documentation
here:

https://docs.pagure.org/copr.copr/user_documentation.html#pagure-integration

or you can just also follow instructions present in Settings->Integrations
in your Copr project. Everything needed is there as well.

Please, enjoy
Copr team
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org/message/RXJ43NPVLOG33XZUT3QMVBR5PZN6HQQ5/

Re: Automating Package Review (Was: fedora-review -- do we have a maintainer?)

[Michal Novotny]

On Thu, Aug 16, 2018 at 11:09 PM Neal Gompa  wrote:

> On Thu, Aug 16, 2018 at 5:04 PM Stephen Gallagher 
> wrote:
> >
> >
> >
> > On Thu, Aug 16, 2018 at 8:30 AM Michal Novotny  wrote:
> >>
> >> On Thu, Aug 16, 2018 at 10:49 AM Zbigniew Jędrzejewski-Szmek <
> zbys...@in.waw.pl> wrote:
> >>>
> >>> f-r currently fails to build (#1603956), it has a bunch of bugs open
> [1]
> >>> and many issues and unhandled pull requests in the upstream repo [2,
> 3].
> >>> The last upstream commit was 2 years ago.
> >>>
> >>> f-r has is annoyingly outdated and gives often outright bad advice
> >>> (for example about BR:gcc or BR:g++). The situation would be
> significantly
> >>> improved if the outstanding PRs were merged.
> >>>
> >>> f-r is also python2-only now, which will be a problem soon since
> >>> support for python2 is waning [4].
> >>>
> >>> Is there any hope of upstream and downstream activity on f-r?
> >>
> >>
> >> I was thinking about getting the fedora-review checks rewritten into
> the standard Test interface
> >> (
> https://qa.fedoraproject.org/docs/libtaskotron/latest/standard-test-interface.html)
> so that they
> >> can be run in Taskotron. We can also just probably run one big
> fedora-review check from
> >> a taskotron test, well, this just came to my mind recently, getting the
> actual solution ready
> >> might take a little bit of time.
> >>  '
> >
> >
> >
> > I'd *really* like to see us get to a point where package review is
> fully-automated. Basically we could just have a web-service that you pass a
> URL to an SRPM plus authenticate with your FAS account and it will perform
> all of the validity checks and if they all pass would go ahead and request
> the branches for you and import the SRPM.
> >
> > Once this is fully automated, we can then *also* add the same checks to
> CI (taskotron, OSCI or whatever) so that on each build it gets rerun, which
> will allow us to help reduce the rate of packages falling out of compliance
> (as well as being updated whenever the checks get made more comprehensive).
> >
> > Historically, we've had human review mainly to protect against two
> things, bundling and unacceptable licenses. In both of these cases, I'd
> like for us to move towards a culture of assuming goodwill on behalf of our
> packagers. Most of the packagers in Fedora have been doing it for a long
> time and know what is and is not acceptable. Optimizing for the minority
> case is wasteful, especially when it adds hurdles and delays to getting
> software delivered.
> >
> > I think what we should instead do is allow things through immediately
> following automated review and just assume that those few cases that slip
> through that should not will get handled after the fact as soon as they are
> noticed (either by someone noticing or an improvement in the automated tool
> discovering the problem).
> >
> > I feel strongly that automated, continuous review would be of far
> greater value to Fedora than front-loading the review process the way we
> have been doing (which serves mostly to discourage people from even
> starting).
>
> I fully agree with this, which is why Tom (Cc'd to this email) and I
> have been sketching out a plan to start moving towards this.
>
> It won't be particularly easy, but we're looking at a step-by-step
> approach to get there. However, if more people are interested in
> contributing to make the end-goal possible, we might be able to get
> there more quickly.
>

Copr team is willing to help.

I think my colleagues will agree with me.
clime


>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/G2P5KSN5AGQP4DTGBVQXP5627JB347PY/
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/IXQK6VKO43J67KZLM7X4DY5C32VAEQ4U/

Re: fedora-review — do we have a maintainer?

[Michal Novotny]

On Thu, Aug 16, 2018 at 3:47 PM Miro Hrončok  wrote:

> > I was actually thinking about this some time ago. If there's a
> > responsive fedora-review maintainer who can respond to people's
> > questions and complains (because if we start running it for every
> > package build and show it in Bodhi, there will be some), I can help to
> > make it run as a Taskotron task. The STI can be just a simple wrapper
> > around the fedora-review binary that downloads the build, runs the
> > command, and generates the results format. It should be similar to
> > rpmlint etc tests we already have in there.
> >
> > The important question is - can it be executed on existing SRPMs/RPMs?
>
> Yes, somehow. It has --no-build option, but it searches the package in
> some mock location. Should be fairly easy to change or fake.
>

In man pages, there is also a tutorial how to do that with koji scratch
builds:

   ·  Download the results:
   koji-download-scratch 

   ·  Invoke fedora-review using --prebuilt, --name options and
--rpm-spec:
   fedora-review --rpm-spec --prebuilt --name my-package

For copr builds it is a little bit easier:

fedora-review --copr-build 

But that version of fedora-review still needs was never released
(https://pagure.io/FedoraReview/commits/devel)


> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/GX5YDAUDMO432RKL3UHCUQKWIWPS7AFJ/
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/RAXSKUDDP3DSKL2IVW5JK26VTXH6J4CX/

Re: fedora-review — do we have a maintainer?

[Michal Novotny]

On Thu, Aug 16, 2018 at 10:49 AM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> f-r currently fails to build (#1603956), it has a bunch of bugs open [1]
> and many issues and unhandled pull requests in the upstream repo [2, 3].
> The last upstream commit was 2 years ago.
>
> f-r has is annoyingly outdated and gives often outright bad advice
> (for example about BR:gcc or BR:g++). The situation would be significantly
> improved if the outstanding PRs were merged.
>
> f-r is also python2-only now, which will be a problem soon since
> support for python2 is waning [4].
>
> Is there any hope of upstream and downstream activity on f-r?
>

I was thinking about getting the fedora-review checks rewritten into the
standard Test interface
(
https://qa.fedoraproject.org/docs/libtaskotron/latest/standard-test-interface.html)
so that they
can be run in Taskotron. We can also just probably run one big
fedora-review check from
a taskotron test, well, this just came to my mind recently, getting the
actual solution ready
might take a little bit of time.


>
> [1]
> https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW=fedora-review_id=9266975=Fedora
> [2] https://pagure.io/FedoraReview/issues
> [3] https://pagure.io/FedoraReview/pull-requests
> [4] https://fedoraproject.org/wiki/Changes/Mass_Python_2_Package_Removal
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/AP3ZVBK4XQVOJ7OB5FUG4EYKAZZIZ37K/
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/PNLJSEGZRTCRKBJFQMODLQS5CPH6KDDC/

Re: fedora-messaging for Copr - what do you need?

[Michal Novotny]

On Sat, Aug 11, 2018 at 10:33 AM Miroslav Suchý  wrote:

> As part of migration of fedmsg from ZMQ to AMQP, I would like to revisit
> what is Copr sending to fedmsg.
>
> Right now we are sending:
>
> 'build.start': {
> 'what': "build start: user:{user} copr:{copr}" \
> " pkg:{pkg} build:{build} ip:{ip} pid:{pid}",
> },
> 'chroot.start': {
> 'what': "chroot start: chroot:{chroot} user:{user}" \
> " copr:{copr} pkg:{pkg} build:{build} ip:{ip}
> pid:{pid}",
> },
> 'build.end': {
> 'what': "build end: user:{user} copr:{copr} build:{build}" \
> " pkg:{pkg} version:{version} ip:{ip} pid:{pid}
> status:{status}",
> },
>
> I have several ideas what we *should* send. Thou, I'd like to hear *your*
> use case. You do not need to be technically
> detailed. Something like:
>
>   I can utilize if you send message and the end/start of XXX and you will
> put there information . I would use this
> information for .
>

If there is nobody listening to current Copr messages, maybe we could
invest into making their format more
easier to parse? I.e. instead of the 'what' fields, actually output some
better structured information that does not
necessitate string splitting on whitespaces. I think with the introduction
of the new messaging system, this
could be a good time to do this.

clime


>
> Miroslav
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OMIVYTJ27O5Z2QPZFSUXHBYLAZ7VPAZX/
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/MBGDSJBGNGIKNONMOUCANQAWLX4APS4G/

Re: fedora-messaging for Copr - what do you need?

[Michal Novotny]

On Mon, Aug 13, 2018 at 12:52 AM Jeff Johnson  wrote:

> Changing Fedora infrastructure to use AMQP brings up a different usage
> case.
>
> Build systems tend to eventually invoke rpmbuild to do the actual build.
>
> Would you like rpmbuild to, say, send time stamped progress messages
> directly through AMQP?
>
> The usage case for AMQP messages in rpmbuild starts with the start/end
> times to collect statistics on package builds, but could also include other
> resource usages needed by rpmbuild.
>
> With RPM+AMQP, there is additional detailed information about
> installations that can be sent directly as well.
>
> Any interest in receiving AMQP messages directly from RPM?
>

Jeff, as far as building goes, note that most build system (includding Copr
with default project settings) invoke rpmbuild inside a chroot with network
disabled. It's probably easier to implement the messaging on higher level.

___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/KSAKHYHPVQVHWJFMEBSL6IF3W2JX6MDM/
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/SAA6EVCS2W43Y5ZPA7NHETNMFE3VPCLF/

Re: RFC: make $releasever return "rawhide" on Rawhide

[Michal Novotny]

On Thu, Aug 2, 2018 at 2:07 PM Neal Gompa  wrote:

> On Tue, Jul 31, 2018 at 9:59 AM Kamil Paral  wrote:
> >
> > Hello devel list,
> >
> > this is a request for comments for a recent proposal I filed at releng
> tracker:
> > https://pagure.io/releng/issue/7445
> >
> > In short, package managers on Rawhide would no longer replace
> $releasever variable with a numerical value (like '29' at this moment, soon
> '30'), but with 'rawhide' string instead. I hope this change will make life
> a bit easier for third-party repos maintainers, for users, for developers
> and sysadmins, and for release engineering. The technical implementation
> can be seen in the ticket (it's the 'Proposed solution 1'), together with a
> long discussion.
> >
> > To provide a longer explanation of the improvements I expect this to
> bring:
> > * Third-party repo maintainers will no longer need to provide two
> different repo files, one for stable Fedora releases using $releasever in
> URLs, and one for Rawhide hardcoding 'rawhide/' in URL and avoiding
> $releasever in URL. (Technically, two repo files are not needed if you
> always use a numbered dir even for Rawhide, but that's maintenance-heavy,
> because you need to change the directory number precisely at Branching
> time). This involves COPR as well.
> > * Users will be able to run commands like "dnf ... --releasever=28" even
> on Rawhide. That doesn't work at the moment, because most repo files don't
> use $releasever and instead have 'rawhide/' hardcoded.
> > * Developers and sysadmins will be able to use the same approach
> regarding repositories for stable Fedora releases and Rawhide. Rawhide will
> no longer be different, requiring special treatment. For example, the same
> repo URL can be used to install a system, or the same URL can be used to
> add an additional repository to an existing system. As an engineer working
> on automation, I was always annoyed how I need to special-case Rawhide
> everywhere (and of course, maintain a config file that states which release
> number Rawhide currently maps to). That will hopefully be no longer
> necessary, or very much reduced.
> > * Fedora release engineers should be able to get rid of
> fedora-repos-rawhide (again, hardcoding 'rawhide/' in URL), and use the
> standard repo files instead (making use of $releasever).
> >
> > There might be other advantages, which I haven't tested or though of.
> >
> > There are also disadvantages. The only one I know of at this moment, is
> that PackageKit is currently incompatible with this change (it uses custom
> logic for populating $releasever, different from dnf logic) and will need
> adjustments.
> >
> > Fedora releng has pre-approved this change in the ticket, and the point
> of this email is to ask for more feedback from all of you. I'd appreciate
> if you could help us identify edge cases we haven't thought of, or point
> out which tools would be incompatible with this change, so that we can
> track them and discuss it with their developers.
> >
>
> This might surprise you, but I actually prefer the current way. It
> makes activating Rawhide an explicit action that can stay carried
> forward. The other thing is, realistically, few third party folks try
> to build for Rawhide because Rawhide snapshots are either too old or
> too broken.
>
> Case in point, the Docker containers for Rawhide effectively look like
> Fedora 28, so what's the point? And upgrading to the latest released
> compose just breaks everything, so it's not useful there either.
>
> This change makes no sense unless we were actually going to make
> Rawhide something that people could rely on. And I'm not sure that's a
> good idea, since we have a nice cadence of releasing every 6
> months(-ish). It's already too hard to keep Rawhide working because of
> GCC breakages and the DNF stack work, and upstreams rely on our
> Rawhide tree to suss out these kinds of things.
>

If we can make rawhide something that people can rely on,
the actual releases will benefit from it as well.


>
> And I would argue that special casing Rawhide is sort of the point,
> but I have no objection to making dnf --releasever=rawhide distro-sync
> also work. I just don't think it's smart to drop the release number
> thing and the fedora-repos-rawhide package.
>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/XGMTZTWR2QYDNSCONEPS4RR567DELMDT/
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 

Re: dnf history - change in how rpmdb checksum is computed

[Michal Novotny]

On Tue, Jul 31, 2018 at 3:40 PM Michal Novotny  wrote:

> On Tue, Jul 31, 2018 at 1:25 PM Jeff Johnson  wrote:
>
>> This simply is not true.
>>
>> Whatever "rpm format" means, historically RPM itself has always gone to
>> some lengths not to expose E: to users to simplify the endless fog of
>> dependency hell clutter.
>>
>
> Yeah, something which is eluding my understanding.
>
> This will be all off-topic by me again but I think it might be worth to be
> mentioned at least...
>
> Given that epoch plays an important role in version comparison (therefore
> during package upgrades), it should be visible in rpm names.
>
> E.g.
>
> $ rpm -q bind-libs
>
> should return:
>
> bind-libs-32:9.11.3-6.fc28.x86_64
>
> on my system.
>
> It should be clear directly from package name why e.g.:
>
> bind-libs-32:9.11.3-6.fc28.x86_64 < bind-libs-33:9.9.4-61.fc28.x86_64
>
> Hiding the epoch does not serve any purpose here (or anywhere). Epoch
> number is something that should be explicitly present in package name so
> that
> users know what's going on when they can't update a package.
>
> Of course, ideally epoch should stay zero if possible and only be used as
> a "safety mechanism" when upstream does something unexpected but even if
> epoch is zero,
> it should still be put into rpm name.
>
> This is very remotely related to:
> https://github.com/rpm-software-management/rpm/issues/450
>
> clime
>
> P.S.: note that if Epoch: tag is missing in a spec file, it should be
> assumed epoch = 0. I think the behavior I am describing is quite natural,
> that's why I am using the word "should".
>

Sorry for the tone in this sentence. I just think rpm is a bit needlessly
"bent" in these areas.

clime


>
> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/XHYTGM2L7PNOWNYKA6T26B7ACDGMX3DD/
>>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/E2IUSM4JGEEE7ZJ34B3FBCOT5PHRUQ2P/

Re: dnf history - change in how rpmdb checksum is computed

[Michal Novotny]

On Tue, Jul 31, 2018 at 1:25 PM Jeff Johnson  wrote:

> This simply is not true.
>
> Whatever "rpm format" means, historically RPM itself has always gone to
> some lengths not to expose E: to users to simplify the endless fog of
> dependency hell clutter.
>

Yeah, something which is eluding my understanding.

This will be all off-topic by me again but I think it might be worth to be
mentioned at least...

Given that epoch plays an important role in version comparison (therefore
during package upgrades), it should be visible in rpm names.

E.g.

$ rpm -q bind-libs

should return:

bind-libs-32:9.11.3-6.fc28.x86_64

on my system.

It should be clear directly from package name why e.g.:

bind-libs-32:9.11.3-6.fc28.x86_64 < bind-libs-33:9.9.4-61.fc28.x86_64

Hiding the epoch does not serve any purpose here (or anywhere). Epoch
number is something that should be explicitly present in package name so
that
users know what's going on when they can't update a package.

Of course, ideally epoch should stay zero if possible and only be used as a
"safety mechanism" when upstream does something unexpected but even if
epoch is zero,
it should still be put into rpm name.

This is very remotely related to:
https://github.com/rpm-software-management/rpm/issues/450

clime

P.S.: note that if Epoch: tag is missing in a spec file, it should be
assumed epoch = 0. I think the behavior I am describing is quite natural,
that's why I am using the word "should".

___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/XHYTGM2L7PNOWNYKA6T26B7ACDGMX3DD/
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ZZTTRZEKH6KXH324OHN5Y44AUZU5RSHA/

Re: tool to order packages by build dependencies (rpmbuild-order)

[Michal Novotny]

Hello,

On Fri, Jul 27, 2018 at 4:56 AM Jens-Ulrik Petersen 
wrote:

> On Fri, Jul 27, 2018 at 12:54 AM Jens-Ulrik Petersen 
> wrote:
>
>> I should test some larger package sets to see how well rpmbuild-order
>> scales too...
>>
>
> BTW are there any tarballs of all the fedora spec files available
> somewhere these days?
>

They are here:
https://src.fedoraproject.org/lookaside/rpm-specs-latest.tar.xz


> Of course I could download srpms, or better: script pulling spec files
> from dist git.
> Just wondered if something is already available?
>
> Jens
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/M3UMMZ273MX5OMOTQIAWZVUOS4OB3Y7N/
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/L5YRQMPGBDRMJ27UGRA3LJMZZ2Q5BEBU/

Re: dnf history - change in how rpmdb checksum is computed

[Michal Novotny]

I would like to see dnf history not being messed up by direct installations
with `rpm -i`.

While `dnf history` is a great feature, it would be even greater if the
related functionality
was implemented directly in rpmdb and both rpm and dnf used that db.
Meaning that
any consistency checks would be in that db too.

Just an idea.

clime

On Tue, Jul 24, 2018 at 12:40 AM Jeff Johnson  wrote:

> The real problem is that both E:N-V-R.A and N-E:V-R.A  are equally
> imprecise.
>
> The concept of "reproducible builds/installs" requires much more complete
> identifiers for serious work. But that was not the question asked in this
> thread.
>
> So calculating both checksums, on rearranged plaintext items, for
> compatibility, kinda misses the underlying need to verify system installs
> on hundreds of machines.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/G5PQ6DZKLVJJYPJCQG2VVQQMRAITETJ3/
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/CVZAQ5IQATEMD6NTDUAQ47A2HWI6VMCV/

Re: Intel's Clear Linux optimizations

[Michal Novotny]

On Mon, Jul 23, 2018 at 8:08 PM Chris Murphy 
wrote:

> On Thu, Jul 19, 2018 at 10:08 AM, Manas Mangaonkar
>  wrote:
> > No offense but can you kindly rephrase whatever you said.Its kinda
> difficult
> > to decipher as your sentences seem to contradict.
>
>
> I need installation instructions to use this kernel, apparently. I've
> got the copr enabled, but can't figure out how to actually install the
> kernel and kernel modules.
>

I think you should be just able to do  $ sudo dnf upgrade kernel

clime


>
>
>
> --
> Chris Murphy
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/AIZIKXISICOK3K5TMGPPQ4ULL6NIY5OR/
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/7QJ4EEIMUVODZJKZQYD57JCVOCCV3RW6/

Re: experiencing dnf Error: Failed to synchronize cache for repo 'fedora' or ''updates'

[Michal Novotny]

On Sun, Jul 22, 2018 at 8:03 PM Kevin Fenzi  wrote:

> On 07/20/2018 11:15 PM, Miro Hrončok wrote:
> > On 20.7.2018 19:56, Kevin Fenzi wrote:
> >> On 07/20/2018 03:55 AM, Michal Novotny wrote:
> >>
> >>>
> >>> I actually already filed the respective bugs:
> >>>
> >>> https://bugzilla.redhat.com/show_bug.cgi?id=1591225
> >>>
> >>> There is even PR:
> >>>
> >>> https://github.com/rpm-software-management/dnf/pull/1109
> >>>
> >>> that got blocked for an unknown reason and mainly unknown period.
> >>>
> >>> I wanted to confirm that more people are experiencing this issue,
> >>> that it's
> >>> not just some "local" network problem. The problem is that dnf does not
> >>> respect max_retries option for a repo when mirror manager is being
> >>> contacted. I have no idea why it hasn't been fixed yet given that it
> >>> affects basically all dnf users and it also quite significantly affects
> >>> building in Copr.
> >>
> >> Thats a good workaround and we should do it, but I sure wish we could
> >> track down when and why those sporadic 503's come from our mirrorlist
> >> containers. ;(
> >>
> >> Perhaps we could add further debugging and track it down. I'll see what
> >> I can do...
> >
> > Can we use something like Sentry? https://sentry.io/
>
> Thats a non free 3rd party service? no thanks. :)
>
> However, smooge spent a bunch of time this weekend tracking a lot of
> this down. It's not solved, but it should be much better now and he's
> going to try and quash the last bits next week.
>

Thank you a lot for this. I think that our infrastructure does really an
admirable job. I greatly
appreciate the effort to fix this.

It would still be good if dnf implemented the retry feature for mirror
manager.
I don't quite understand why block
https://github.com/rpm-software-management/dnf/pull/1109.

clime


>
> kevin
>
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/C273DWHLFF4CXIKQCNG637JS5FB7JRCO/
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ZN6FE33VKZTLGTQJFL7A6FUFCCEJ6BLZ/

Re: experiencing dnf Error: Failed to synchronize cache for repo 'fedora' or ''updates'

[Michal Novotny]

On Fri, Jul 20, 2018 at 10:45 AM Kamil Paral  wrote:

> On Fri, Jul 20, 2018 at 9:37 AM, Miro Hrončok  wrote:
>
>> On 20.7.2018 06:25, Michal Novotny wrote:
>>
>>> Hello,
>>>
>>> I am occasionally experiencing the following error in my day-to-day dnf
>>> use:
>>>
>>>  Failed to synchronize cache for repo 'fedora'
>>>
>>> or
>>>
>>>  Failed to synchronize cache for repo 'updates'
>>>
>>> I've had that happened even in local mock builds.
>>>
>>> Do you also experience this error upon dnf operations like `dnf install`
>>> or `dnf refresh` or in local mock builds?
>>>
>>>
>> Happened to me yesterday. And immediate rerun "fixed" it. Maybe we can
>> add some retrying to mock?
>>
>
> We see this quite frequently in Taskotron, because we execute thousands
> jobs a day. I had to add "retry" keyword to all ansible tasks that use the
> dnf module. The reason is that MirrorManager sometimes returns an HTTP 5xx
> error (but when you try again, it works fine).
>
> It would help if DNF retried failed network requests (5xx codes), that's
> the best place to fix this for everybody. Anybody cares enough to file a
> bug and link it here?
>

I actually already filed the respective bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1591225

There is even PR:

https://github.com/rpm-software-management/dnf/pull/1109

that got blocked for an unknown reason and mainly unknown period.

I wanted to confirm that more people are experiencing this issue, that it's
not just some "local" network problem. The problem is that dnf does not
respect max_retries option for a repo when mirror manager is being
contacted. I have no idea why it hasn't been fixed yet given that it
affects basically all dnf users and it also quite significantly affects
building in Copr.

clime
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ZY4MPSHEIDSZHOFJGP7RPZRKOCLMGUY5/

experiencing dnf Error: Failed to synchronize cache for repo 'fedora' or ''updates'

[Michal Novotny]

Hello,

I am occasionally experiencing the following error in my day-to-day dnf use:

Failed to synchronize cache for repo 'fedora'

or

Failed to synchronize cache for repo 'updates'

I've had that happened even in local mock builds.

Do you also experience this error upon dnf operations like `dnf install` or
`dnf refresh` or in local mock builds?

Thank you
clime
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/RPRS3I7QTMLGLYXXRP2R3EQE3G2R6MY6/

copr nomenclature

[Michal Novotny]

Hello,

lots of times, I see name "copr", "Copr", or "COPR" used somewhere but it's
almost never used correctly for the given context. So I would like to make
it clear, what's the correct way to write it down to get the meaning right.

"Copr" or "COPR" = service providing space for community projects

"copr" or "Copr project" = a single community project

So there are two variants how to refer to service ("Copr" and "COPR").

And there are two variants how to refer to a singular project ("copr" and
"Copr project").

- (minor additional notes to be ignored) -

When referring to a singular project, just saying "copr" is enough. "co"
stands for "community", "pr" stands for "project".

When you write down "Copr project", it literally means "Community projects
project" so it's a bit redundant to write it down that way.

If you liked to refer to the Fedora instance of Copr service, you would
write "Fedora Copr".

If you liked to ignore the previous rule or made it nice for typography,
you would write "fedora copr" like our logo does. This is also good for IRC.

I don't really mind how people write it down but I think it's good to
provide at least some guide in case somebody needs to think about this :).

clime
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/MCTEFU4H7QFUXEFQLPRREGD5RJPE4PPM/

Re: Anyone interested in Testing the wireframes of the Fedora Community App?

[Michal Novotny]

I can test too.

On Mon, Apr 16, 2018 at 10:19 AM, mohammad luqman 
wrote:

>  send me the wireframes too.
>
> On 16 April 2018 at 11:59, Clement Verna  wrote:
>
>> On 14 April 2018 at 00:08, Abhishek Sharma 
>> wrote:
>> > Sent you the invite, Umar. Thanks!
>> >
>> > Will love to see more participation from the community :-)
>> >
>> > On Sat, Apr 14, 2018 at 3:29 AM, Umar Parooq 
>> > wrote:
>> >>
>> >> I am in.
>> >>
>> >> On Fri, Apr 13, 2018, 10:52 PM Abhishek Sharma <
>> guywhodesi...@gmail.com>
>> >> wrote:
>> >>>
>> >>> Hello!
>> >>>
>> >>> So I have been working on the wireframes for the revamped Fedora
>> >>> Community App (as a part of my GSoC proposal) and I am ready to share
>> the
>> >>> V1.
>> >>>
>> >>> I need some people to volunteer for the wireframe testing. In the
>> >>> process, you will be asked to do very simple tasks (which will hardly
>> take 2
>> >>> minutes) on a clickable prototype. I can learn from the insights of
>> testing
>> >>> to iterate on the design of the application. Basically what's working
>> and
>> >>> what's not. I believe to design the best UX, we need to pay attention
>> to
>> >>> what users do.
>> >>>
>> >>> Please reply to this email if you're interested so that I can invite
>> you
>> >>> for the testing.
>>
>> You can add me too :)
>>
>> >>>
>> >>> Thanks :-)
>> >>>
>> >>> Best,
>> >>> Abhishek
>> >>> ___
>> >>> devel mailing list -- devel@lists.fedoraproject.org
>> >>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> >>
>> >>
>> >> ___
>> >> devel mailing list -- devel@lists.fedoraproject.org
>> >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> >>
>> >
>> >
>> > ___
>> > devel mailing list -- devel@lists.fedoraproject.org
>> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> >
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>>
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Review Swap

[Michal Novotny]

Hello,

I would like to do rename of rpkg-client (
https://src.fedoraproject.org/rpms/rpkg-client) to rpkg-util and also I
would like to go the package again through a review process because the
spec might deserve some care:
https://bugzilla.redhat.com/show_bug.cgi?id=1563184

Can I possibly swap reviews with somebody?
clime
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Avoiding Jargon: dist-git

[Michal Novotny]

On Sun, Mar 25, 2018 at 7:29 PM, Christopher <ctubb...@fedoraproject.org>
wrote:

> On Sun, Mar 25, 2018 at 4:43 AM Michal Novotny <cl...@redhat.com> wrote:
>
>> On Sun, Mar 25, 2018 at 12:03 AM, Neal Gompa <ngomp...@gmail.com> wrote:
>>
>>> On Sat, Mar 24, 2018 at 6:57 PM, Ben Rosser <rosser@gmail.com>
>>> wrote:
>>> >
>>> > Looking at the dist-git README further reinforces this impression. The
>>> > first sentence says: "DistGit (Distributed Git) is Git with additional
>>> > data storage". My initial reaction to that is "so, it is basically
>>> > just git". My second reaction is "why does additional data storage
>>> > somehow make git (a distributed version control system) even _more_
>>> > distributed?".
>>> >
>>>
>>> I might be misremembering, but I think Dist-Git was originally short
>>> for "Distribution Git". It was the first attempt to marry a binary
>>> store to Git, predating git-annex and Git LFS by several years.
>>>
>>
>> Ha, okay, actually, "distribution Git" makes more sense. Thank you!
>>
>> I've changed it in the README.
>>
>>
>
> Which README? Where is it located?
>

Here: https://github.com/release-engineering/dist-git

I agree that using "Fedora Package Source Repository"
instead of just "Fedora DistGit" is clearer (but also longer
so I, personally, like your Glossary suggestion the best).


>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Avoiding Jargon: dist-git

[Michal Novotny]

On Sun, Mar 25, 2018 at 12:03 AM, Neal Gompa  wrote:

> On Sat, Mar 24, 2018 at 6:57 PM, Ben Rosser  wrote:
> >
> > Looking at the dist-git README further reinforces this impression. The
> > first sentence says: "DistGit (Distributed Git) is Git with additional
> > data storage". My initial reaction to that is "so, it is basically
> > just git". My second reaction is "why does additional data storage
> > somehow make git (a distributed version control system) even _more_
> > distributed?".
> >
>
> I might be misremembering, but I think Dist-Git was originally short
> for "Distribution Git". It was the first attempt to marry a binary
> store to Git, predating git-annex and Git LFS by several years.
>
> Unlike VCSes like CVS and SVN, Git does not handle binaries very well,
> and so they needed to be moved out of the VCS into an external store.
> This was the first attempt at it, and it works, though no one else
> ever adopted it due to some of the clunkiness with it (the undefined
> sources file format, inability to cleanly define where the sources are
> actually stored, etc.).
>
> Those issues could probably be solved today, but I don't think anyone
> really cares to fix that in a way where Dist-Git would integrate more
> cleanly into Git itself.
>

Oh,  I actually care about it.


>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Avoiding Jargon: dist-git

[Michal Novotny]

On Sun, Mar 25, 2018 at 12:03 AM, Neal Gompa  wrote:

> On Sat, Mar 24, 2018 at 6:57 PM, Ben Rosser  wrote:
> >
> > Looking at the dist-git README further reinforces this impression. The
> > first sentence says: "DistGit (Distributed Git) is Git with additional
> > data storage". My initial reaction to that is "so, it is basically
> > just git". My second reaction is "why does additional data storage
> > somehow make git (a distributed version control system) even _more_
> > distributed?".
> >
>
> I might be misremembering, but I think Dist-Git was originally short
> for "Distribution Git". It was the first attempt to marry a binary
> store to Git, predating git-annex and Git LFS by several years.
>

Ha, okay, actually, "distribution Git" makes more sense. Thank you!

I've changed it in the README.

clime


>
> Unlike VCSes like CVS and SVN, Git does not handle binaries very well,
> and so they needed to be moved out of the VCS into an external store.
> This was the first attempt at it, and it works, though no one else
> ever adopted it due to some of the clunkiness with it (the undefined
> sources file format, inability to cleanly define where the sources are
> actually stored, etc.).
>
> Those issues could probably be solved today, but I don't think anyone
> really cares to fix that in a way where Dist-Git would integrate more
> cleanly into Git itself.
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Goodbye nvr.rsplit('-', 2), hello modularity

[Michal Novotny]

On Fri, Mar 23, 2018 at 7:24 AM, Michal Novotny <cl...@redhat.com> wrote:
> On Tue, Mar 20, 2018 at 3:31 PM, Jan Kaluza <jkal...@redhat.com> wrote:
>> On Tue, Mar 20, 2018 at 10:06 AM, Michal Novotny <cl...@redhat.com> wrote:
>>>
>>> The question here is why don't we actually implement the modularity
>>> the simple way.
>>>
>>> Let's suppose I would like to make nodejs-8 available in EPEL7.
>>>
>>> The most effortless way would be to create subdirectory called 8 at
>>> src.fedoraproject.org/rpms/nodejs
>>> with the updated spec file and sources for the bumped major version of
>>> the nodejs package.
>>
>>
>> What if your module contains packages coming from multiple SRPMs and they
>> depend on each other?
>
> Well, my module wouldn't be coming from multiple SRPMs because my
> module is just a normal package.
>
> The problem with modularity is that the name does not really fit what
> it does, which is kind of important because wrong names make
> implementation much harder as you cannot rely on your common
> sense.
>
> When I think of a module, rpm ultimately comes to mind. That's kind of
> a unit that makes up an operating system.
>
> I highly doubt modularity can change it unless it invents its own package
> format. So I think it would be good to call it differently even in the 
> tooling.
>
> So let's try to figure out a better name for modulemd.
>
> Basically, the final product of modulemd is a repo with some built rpm
> packages in it (if I saw the latest development correctly, we were squashing
> multiple of those repos into a single one but we wouldn't need to do that).
>
> For users, a repo represents something like a stream of content. So
> streammd would be already a better name.
>
> But even a better name would be coprmd because you can think about
> the current "modulemd" as a copr (community project) being formally
> described in a file. Product of a copr project is also a repo so it fits.
>
> Stream name here:
>
> https://github.com/fedora-modularity/libmodulemd/blob/master/spec.v2.yaml#L13
>
> is basically a project name.
>
>
> The content specified here:
>
> https://github.com/fedora-modularity/libmodulemd/blob/master/spec.v2.yaml#L305
>
> are basically definitions of SCM packages.

That link should have pointed here:
https://github.com/fedora-modularity/libmodulemd/blob/master/spec.v2.yaml#L233

>
> And then there are some fields like:
>
> version: 20160927144203
>
> context: c0ffee43
>
> which doesn't really belong there imho but instead belong to the final
> built repository (= copr snapshot) as a part of repodata (if anywhere).
>
> So I think it would be good to keep talking about packages when
> we talk about modules.
>
> clime
>
>>
>> Jan Kaluza
>>
>>>
>>>
>>> For fedpkg to be able to upload and download sources for that
>>> subdirectory (submodule), the attached
>>> single-line patch is needed in python-rpkg. There are a few more
>>> changes needed to make srpm
>>> importing work but it should be basically almost done as well.
>>>
>>> Koji then just needs to learn how to build DistGit repositories
>>> containing submodules where
>>> submodule is any subdirectory containing a spec file. When Koji
>>> discovers all the submodules
>>> in a repository, it can start an srpm and a consequent rpm build for
>>> each of them.
>>>
>>> It is a very similar approach to what find_packages from python
>>> setuptools implements. It
>>> recognizes subpackages based on the presence of __init__.py file. The
>>> only difference here
>>> is that we will be recognizing subpackages (=submodules) by the
>>> presence of *.spec file.
>>>
>>> Everything else should be pretty much the same otherwise. Koji builds
>>> nodejs-6 and nodejs-8 rpms
>>> both with el7 disttag and both of these can go through the Bodhi
>>> update process separately.
>>>
>>> Of course, the question is if you can actually build and run nodejs-8
>>> in EL7 successfully but
>>> I think that will always be a problem no matter what the implementation
>>> is.
>>>
>>> clime
>>>
>>> On Mon, Mar 19, 2018 at 8:08 PM, Jan Kaluza <jkal...@redhat.com> wrote:
>>> >
>>> >
>>> > On Mon, Mar 19, 2018 at 4:43 PM, Adam Williamson
>>> > <adamw...@fedoraproject.org> wrote:
>>> >>
>>> >> On Mon, 2018-03-19 at 10:58 +0100, 

Re: Goodbye nvr.rsplit('-', 2), hello modularity

[Michal Novotny]

On Tue, Mar 20, 2018 at 3:31 PM, Jan Kaluza <jkal...@redhat.com> wrote:
> On Tue, Mar 20, 2018 at 10:06 AM, Michal Novotny <cl...@redhat.com> wrote:
>>
>> The question here is why don't we actually implement the modularity
>> the simple way.
>>
>> Let's suppose I would like to make nodejs-8 available in EPEL7.
>>
>> The most effortless way would be to create subdirectory called 8 at
>> src.fedoraproject.org/rpms/nodejs
>> with the updated spec file and sources for the bumped major version of
>> the nodejs package.
>
>
> What if your module contains packages coming from multiple SRPMs and they
> depend on each other?

Well, my module wouldn't be coming from multiple SRPMs because my
module is just a normal package.

The problem with modularity is that the name does not really fit what
it does, which is kind of important because wrong names make
implementation much harder as you cannot rely on your common
sense.

When I think of a module, rpm ultimately comes to mind. That's kind of
a unit that makes up an operating system.

I highly doubt modularity can change it unless it invents its own package
format. So I think it would be good to call it differently even in the tooling.

So let's try to figure out a better name for modulemd.

Basically, the final product of modulemd is a repo with some built rpm
packages in it (if I saw the latest development correctly, we were squashing
multiple of those repos into a single one but we wouldn't need to do that).

For users, a repo represents something like a stream of content. So
streammd would be already a better name.

But even a better name would be coprmd because you can think about
the current "modulemd" as a copr (community project) being formally
described in a file. Product of a copr project is also a repo so it fits.

Stream name here:

https://github.com/fedora-modularity/libmodulemd/blob/master/spec.v2.yaml#L13

is basically a project name.


The content specified here:

https://github.com/fedora-modularity/libmodulemd/blob/master/spec.v2.yaml#L305

are basically definitions of SCM packages.

And then there are some fields like:

version: 20160927144203

context: c0ffee43

which doesn't really belong there imho but instead belong to the final
built repository (= copr snapshot) as a part of repodata (if anywhere).

So I think it would be good to keep talking about packages when
we talk about modules.

clime

>
> Jan Kaluza
>
>>
>>
>> For fedpkg to be able to upload and download sources for that
>> subdirectory (submodule), the attached
>> single-line patch is needed in python-rpkg. There are a few more
>> changes needed to make srpm
>> importing work but it should be basically almost done as well.
>>
>> Koji then just needs to learn how to build DistGit repositories
>> containing submodules where
>> submodule is any subdirectory containing a spec file. When Koji
>> discovers all the submodules
>> in a repository, it can start an srpm and a consequent rpm build for
>> each of them.
>>
>> It is a very similar approach to what find_packages from python
>> setuptools implements. It
>> recognizes subpackages based on the presence of __init__.py file. The
>> only difference here
>> is that we will be recognizing subpackages (=submodules) by the
>> presence of *.spec file.
>>
>> Everything else should be pretty much the same otherwise. Koji builds
>> nodejs-6 and nodejs-8 rpms
>> both with el7 disttag and both of these can go through the Bodhi
>> update process separately.
>>
>> Of course, the question is if you can actually build and run nodejs-8
>> in EL7 successfully but
>> I think that will always be a problem no matter what the implementation
>> is.
>>
>> clime
>>
>> On Mon, Mar 19, 2018 at 8:08 PM, Jan Kaluza <jkal...@redhat.com> wrote:
>> >
>> >
>> > On Mon, Mar 19, 2018 at 4:43 PM, Adam Williamson
>> > <adamw...@fedoraproject.org> wrote:
>> >>
>> >> On Mon, 2018-03-19 at 10:58 +0100, Stanislav Ochotnicky wrote:
>> >> > On Mon 19 Mar 2018 09:38:58 AM GMT Fabio Valentini wrote:
>> >> > > So you think having to send a request to a web service instead of
>> >> > > just
>> >> > > parsing a string locally with one line of code is a good trade-off
>> >> > > for
>> >> > > allowing dashes?
>> >> >
>> >> > This has been mentioned several times in this thread and I think
>> >> > there's
>> >> > a misunderstanding around this.
>> >> >
>> >> > So: When your tool/whatever works with modules i

Re: COPR src.fp.o auto-rebuilds

[Michal Novotny]

On Tue, Mar 20, 2018 at 1:22 PM, Michal Schorm <msch...@redhat.com> wrote:
> Thanks for the tip.
> I just started using it and it works great! :)
>
> I'm not hooking forked repository, but private branches instead.
> The use case is to have multiple versions of packages available in
> COPR - especially MariaDB 10.3 and MySQL 8 which are still in
> developement.

I am glad it works. Let me know if you find anything that we can
improve on our side.

clime

>
>
> --
>
> Michal Schorm
> Associate Software Engineer
> Core Services - Databases Team
> Red Hat
>
>
> On Tue, Feb 27, 2018 at 12:04 AM, Michal Novotny <cl...@redhat.com> wrote:
>> Hello,
>>
>> you can now very easily setup auto-rebuilds for your src.fp.o package:
>>
>> 1) make a SCM package in COPR with Clone URL pointing to the src.fp.o fork
>> (please, use the https:// cloning option)
>> 2) make sure "Webhook Rebuild" checkbox is checked when you are creating the
>> package
>> 3) Go to settings for your package at src.fp.o and almost at the bottom in
>> Hooks->Fedmsg section, check "Activate" checkbox and then click on "Update"
>> button.
>>
>> If your package is a main package (not a fork), then you can omit step 3.
>>
>> See https://pagure.io/copr/copr/issue/142 for more info.
>> COPR team
>>
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: COPR src.fp.o auto-rebuilds

[Michal Novotny]

On Tue, Mar 20, 2018 at 2:54 PM, Miro Hrončok <mhron...@redhat.com> wrote:
> On 20.3.2018 14:33, Michal Novotny wrote:
>>
>> Hello,
>>
>> On Tue, Mar 20, 2018 at 1:55 PM, Miro Hrončok <mhron...@redhat.com> wrote:
>>>
>>> On 27.2.2018 00:04, Michal Novotny wrote:
>>>>
>>>>
>>>> Hello,
>>>>
>>>> you can now very easily setup auto-rebuilds for your src.fp.o package:
>>>>
>>>> 1) make a SCM package in COPR with Clone URL pointing to the src.fp.o
>>>> fork
>>>> (please, use the https:// cloning option)
>>>> 2) make sure "Webhook Rebuild" checkbox is checked when you are creating
>>>> the package
>>>> 3) Go to settings for your package at src.fp.o and almost at the bottom
>>>> in
>>>> Hooks->Fedmsg section, check "Activate" checkbox and then click on
>>>> "Update"
>>>> button.
>>>
>>>
>>>
>>> This is awesome! Thanks.
>>>
>>> I've pushed several commits at once and copr triggered a build for every
>>> one
>>> of them. It would make sense in my POV to only trigger once per push. Is
>>> there a technical reason for current behavior, or is it intentional?
>>
>>
>> This is probably not intentional. I would need to check the fedmsgs
>> that triggered the
>> builds. If there was just a single originating message, then it is a
>> bug. Otherwise, something
>> on DistGit side would need to be optimized.
>>
>
> https://apps.fedoraproject.org/datagrepper/raw?user=churchyard
> see 2018-03-20 12:51:50 git.receive messages

Right, I think these were mostly pushed to the main (not-forked) DistGit repos?
For main repos, the original DistGit fedmsg is generated (e.g.
https://apps.fedoraproject.org/datagrepper/id?id=2018-4121a27f-c72b-43d7-92b2-044095bb67e7_raw=true=extra-large)
and the original DistGit fedmsgs are always just for a single commit
(stored in rev field).

Whereas if you push to a fork, a pagure fedmsg is generated and that
fedmsg can group several commits together (related message fields are
start_commit and end_commit).

We would need to e.g. allow sending pagure fedmsgs even for pushes
into the main repos to be able to build just once per a push event.
However, (while it is not exactly necessary) it's not that bad to have
ever single commit build in COPR, I think :).

clime

>
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Goodbye nvr.rsplit('-', 2), hello modularity

[Michal Novotny]

The question here is why don't we actually implement the modularity
the simple way.

Let's suppose I would like to make nodejs-8 available in EPEL7.

The most effortless way would be to create subdirectory called 8 at
src.fedoraproject.org/rpms/nodejs
with the updated spec file and sources for the bumped major version of
the nodejs package.

For fedpkg to be able to upload and download sources for that
subdirectory (submodule), the attached
single-line patch is needed in python-rpkg. There are a few more
changes needed to make srpm
importing work but it should be basically almost done as well.

Koji then just needs to learn how to build DistGit repositories
containing submodules where
submodule is any subdirectory containing a spec file. When Koji
discovers all the submodules
in a repository, it can start an srpm and a consequent rpm build for
each of them.

It is a very similar approach to what find_packages from python
setuptools implements. It
recognizes subpackages based on the presence of __init__.py file. The
only difference here
is that we will be recognizing subpackages (=submodules) by the
presence of *.spec file.

Everything else should be pretty much the same otherwise. Koji builds
nodejs-6 and nodejs-8 rpms
both with el7 disttag and both of these can go through the Bodhi
update process separately.

Of course, the question is if you can actually build and run nodejs-8
in EL7 successfully but
I think that will always be a problem no matter what the implementation is.

clime

On Mon, Mar 19, 2018 at 8:08 PM, Jan Kaluza  wrote:
>
>
> On Mon, Mar 19, 2018 at 4:43 PM, Adam Williamson
>  wrote:
>>
>> On Mon, 2018-03-19 at 10:58 +0100, Stanislav Ochotnicky wrote:
>> > On Mon 19 Mar 2018 09:38:58 AM GMT Fabio Valentini wrote:
>> > > So you think having to send a request to a web service instead of just
>> > > parsing a string locally with one line of code is a good trade-off for
>> > > allowing dashes?
>> >
>> > This has been mentioned several times in this thread and I think there's
>> > a misunderstanding around this.
>> >
>> > So: When your tool/whatever works with modules it will have to have
>> > module metadata available in some form.
>>
>> What if I don't want to work with modules at all, just with information
>> about modules?
>>
>> What if I just want to write a tool that parses fedmsgs about module
>> builds in Koji and does something that depends on module names, streams
>> and versions? (e.g. some sort of changelog thing)
>
>
> Your tool can use good old buildsys.build.state.change fedmsg with the well
> known name/version/release fields like this:
>
> https://apps.stg.fedoraproject.org/datagrepper/raw?topic=org.fedoraproject.stg.buildsys.build.state.change
>
> That's staging, because it's easier for me to find the module builds there
> :).
>
> Unfortunatelly, Koji does not add "type" field there, so you cannot find out
> if that's module or not. But in case your tool is doing general changelog
> per Koji build, it will work quite well with modules without you even
> noticing you are working with modules.
>
> In case of tools, you can even query koji using its api and pass the
> name/version/release there, instead of NVR.
>
> If you query Koji for the module build, you will actually find whole module
> metadata in "extra" part of the build.
>
> In case you are OK with using MBS fedmsgs, you can use the fedmsgs Nils
> already sent in this thread.
>
> Regards,
> Jan Kaluza
>
>> --
>> Adam Williamson
>> Fedora QA Community Monkey
>> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
>> http://www.happyassassin.net
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
From 51c184a0ea77a6b000d65045f87efc614d26fcbd Mon Sep 17 00:00:00 2001
From: clime 
Date: Tue, 20 Mar 2018 08:53:01 +0100
Subject: [PATCH] patch for modularity

---
 pyrpkg/__init__.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/pyrpkg/__init__.py b/pyrpkg/__init__.py
index 74cdbfc..c182b90 100644
--- a/pyrpkg/__init__.py
+++ b/pyrpkg/__init__.py
@@ -740,7 +740,7 @@ class Commands(object):
 
 self.log.debug('Creating repo object from %s', self.path)
 try:
-self._repo = git.Repo(self.path)
+self._repo = git.Repo(self.path, search_parent_directories=True)
 except (git.InvalidGitRepositoryError, git.NoSuchPathError):
 raise rpkgError('%s is not a valid repo' % self.path)
 
-- 
2.14.3

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Using the Fedora infra for crypto-mining

[Michal Novotny]

Hello Dridi,

On Mon, Mar 19, 2018 at 10:13 AM, Dridi Boukelmoune
 wrote:
> Hello list,
>
> Since I work on a project that uses the Coverity Scan free plan for
> open source software it came to my attention today that free scans
> were put on hold and resumed recently because people were abusing it
> for crypto mining.
>
> Since I couldn't find any discussion on this list around this topic I
> figured I could start one, if only to ask whether this is a
> possibility for Fedora. If I'm not mistaken you don't need much more
> than a FAS account to host COPR repositories and run builds.
>
> Could someone abuse the infra in such a way?

Builds are being automatically terminated if not finished in 18 hours.
The virtual machines that builds run on are also not particularly strong
so if anyone tried to mine something by this method, he wouldn't
get particularly rich :).

Also, we would probably find out because of long-running builds
are easy to discover thanks to the public build queue (it is also not
like we would be running 1000 builds at once, then it would be hard
to track).

So I wouldn't be really worried about this.

Best regards
clime

>
> Cheers,
> Dridi
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: --module-name or some other name?

[Michal Novotny]

Hello,

On Wed, Mar 14, 2018 at 1:56 PM, Chenxiong Qi  wrote:
> Hi all,
>
> Recently, a fedpkg global option --module-name could confuse some
> packagers easily because word "module" is sort of ambiguous with the
> module introduced by Fedora Modularity. This option is used for
> specifying a repository name manually instead of guessing that from git
> push URL or the macro name in SPEC file.
>
> To avoid the confusion, it would be nice to use another name, for
> example --repository-name or --package-name. I personally prefer the
> former one. Before making this change, I'd like to hear your thoughts.
>
> *  --repository-name or --package-name, what do you think which one is
> proper for fedpkg?
>
> * How do you use --module-name in your practice?
>
> * Is it ok to rename it directly without keeping the original name, or
> to keep --module-name for a period of time so that you have time to
> migrate to new name?

If there needs to be a change at all, then I would also be in favor of
--name and --namespace.

clime

>
> Thanks.
>
> Regards,
> Chenxiong Qi
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Escaping macros in %changelog

[Michal Novotny]

Hello,

On Fri, Feb 9, 2018 at 10:57 PM, Michal Novotny <cl...@redhat.com> wrote:

> Hello,
>
> On Fri, Feb 9, 2018 at 3:22 PM, Panu Matilainen <pmati...@redhat.com>
> wrote:
>
>> On 02/09/2018 03:34 PM, Josh Boyer wrote:
>>
>>> On Thu, Feb 8, 2018 at 1:32 PM, Matthew Miller <mat...@fedoraproject.org>
>>> wrote:
>>>
>>>> On Thu, Feb 08, 2018 at 05:02:10PM +0100, Igor Gnatenko wrote:
>>>>
>>>>> It seems that a lot of people have %file, %check, %build, %whatsoever
>>>>> in their changelog section.
>>>>> Is there any reason I should not go and automatically escape them?
>>>>>
>>>>
>>>> This seems like a lot of churn. If we're going to do this, let's go big
>>>> and get rid of RPM changelogs.
>>>>
>>>> When we have a package update, there are basically two different kinds
>>>> of changelog information. Well, three.
>>>>
>>>> First, there's the upstream changelog. We don't generally do much with
>>>> these except maybe package as %doc.
>>>>
>>>> Second, there's package maintainer changelogs. These are really
>>>> redundant with the dist-git log. We don't really need this anymore.
>>>> It's just a chore.
>>>>
>>>> Third, though, there's end-user information. Why should a user care
>>>> *This* is redundant with bodhi update info, at least if packagers fill
>>>> that out, and it often also duplicates upstream changelogs, *and* it
>>>> often also covers things like "fixes CVE-' also carried the
>>>> specfile changelog.
>>>>
>>>> This is neither most helpful for user *nor* ideal for packages. Why
>>>> don't we drop changelogs entirely in favor of 1) using the dist-git
>>>> logs for specfile maintainers and 2) providing the end-user information
>>>> in a different way. This could be through specially formatted log lines
>>>> going with the commit, or it could be simply in a standard separate
>>>> file (`fedora.user-visible-changes`). Optionally, it could include both
>>>> a high level end-user summary, and a detailed description for sysadmins
>>>> and the curious.
>>>>
>>>> Wherever it lives, this would be read by Bodhi, so there's
>>>> would be need to enter it more than once. And, perhaps a DNF plugin
>>>> could be made to read and display this information for systems
>>>> administrators.
>>>>
>>>
>>> I fully support the removal of RPM changelogs.  However, you've missed
>>> two cases:
>>>
>>> 1) Rawhide, which doesn't go through bodhi
>>> 2) Fedora release upgrades, which don't go through bodhi
>>>
>>> Now, I would actually LOVE for Rawhide to go through bodhi but
>>> whatever.  The release -> release upgrade isn't really solvable that
>>> way though.
>>>
>>> Someone else suggested changelogs could be inserted during koji build
>>> time.  That would be interesting to look into.
>>>
>>
>> Koji, or fedpkg, or better yet some hook in rpm itself. It's not exactly
>> rocket science we're talking about here if people are ready to give it a go.
>>
>
> I actually looked yesterday if I could make a PR for rpm implementing it
> but I couldn't really find a good way to do it. So I decided to implement it
> in `rpkg-client` (https://pagure.io/rpkg-client/branch/spec_preprocessor
> - basically a hack upon python-rpkg library) by spec preprocessing. So,
> with that development version of rpkg, you can have specs (or rather spec
> templates) like this in your Git project:
>
> Name:   {{{ git_name }}}
> Version:{{{ git_version }}}
> Release:1%{?dist}
> Summary:This is a test package.
>
> License:GPLv2+
> URL:https://someurl.org
>
> Source: {{{ make_source }}}
>
> %description
> This is a test package.
>
> %prep
> {{{ setup }}}
>
> {{{ git_change_log }}}
>
> rpkg will take that spec template and replace the {{{ ... }}} tags with
> standard output of the commands inside the braces (git_name, git_version,
> make_source, setup, git_change_log are all shell functions). Afterwards,
> the generated spec is used to e.g. create an srpm (done by `rpkg srpm`
> command).
>

I have implemented the idea here: https://pagure.io/rpkg-util/pull-request/7.
It is now under review. Please, join. Starting docs are here:
https://docs.pagure.org/rpkg-util/tutorials.html#spec-templates-from-scratch


>

f28-ppc64le chroots finally working in COPR

[Michal Novotny]

Hello,

the fedora-28-ppc64le chroot was no working up until now due to lack of
compose. This was resolved however in issue.
https://pagure.io/releng/issue/7357

clime
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

f28-ppc64le chroots finally working in COPR

[Michal Novotny]

Hello,

the fedora-28-ppc64le chroot was no working up until now due to lack of
compose. This was resolved however in issue.
https://pagure.io/releng/issue/7357

clime
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org

COPR src.fp.o auto-rebuilds

[Michal Novotny]

Hello,

you can now very easily setup auto-rebuilds for your src.fp.o package:

1) make a SCM package in COPR with Clone URL pointing to the src.fp.o fork
(please, use the https:// cloning option)
2) make sure "Webhook Rebuild" checkbox is checked when you are creating
the package
3) Go to settings for your package at src.fp.o and almost at the bottom in
Hooks->Fedmsg section, check "Activate" checkbox and then click on "Update"
button.

If your package is a main package (not a fork), then you can omit step 3.
See https://pagure.io/copr/copr/issue/142 for more info.
COPR team
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Removal of BuildRoot

[Michal Novotny]

On Thu, Feb 15, 2018 at 10:36 AM, Igor Gnatenko <
ignatenkobr...@fedoraproject.org> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On Thu, 2018-02-15 at 10:17 +0100, Michal Novotny wrote:
> > I feel PRs are better for this sort of stuff. Mainly because people are
> > informed why exactly this change is made,
> > they can read the guidelines and then merge the change when they are sure
> > they understand it. It helps spreading knowledge
> > and keeping community involved. Python team did it very well in their
> > "Fedora's
> > Switch to Python 3 effort
> > <https://fedoraproject.org/wiki/FinalizingFedoraSwitchtoPython3>", i
> think.
>
> Python changes are needed to be carefully inspected while this thing is
> about
> removing **single line** which is not needed for **10 years**. Also
> guidelines
> for Python changed recently while BuildRoot tag is not needed for many
> years
> and everyone should be aware of that.
>
Also look what's the progress of python→python2. It's not close to complete
> in
> any way. Most of PRs are opened and no one looks into them.
>

As far as I know, they are going to auto-merge the PR after some period of
time,
which is probably a pretty good solution.


>
> > There are other reasons too. Some projects might keep the original spec
> > file somewhere
> > else than in DistGit and they need to port those changes back to the
> > original spec files. It is much more pleasant to have those
> > changes placed in a PR with a relevant description, which will also give
> > them a proper notification. Otherwise, they might end
> > up solving some unexpected conflicts next time they import their new spec
> > files into DistGit.
>
> You probably not aware, but we have guidelines about exactly this thing[0].
> > Fedora's git repository is the canonical location for Fedora spec files.
> Maintainers MUST expect that other maintainers and automated tooling will
> make
> changes to their packages, potentially without communicating prior to
> doing so
> (though communication is always encouraged). If some maintainers are also
> attempting to keep copies of a spec in an outside repository, they MUST be
> prepared to merge changes made to the spec in Fedora's repository, and
> MUST NOT
> overwrite those changes with a copy from an external repository or using
> fedpkg
> import.
>

I am overwriting changes in %changelog from auto-rebuilds all the time
because I don't
really want messages in %changelog like:

"Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild;

I think that by PRs (that would get automatically merged after some time)
more could be actually achieved in a long run. If you make a PR and you give
it a good description, it will probably reach more people. But I admit it's
more
difficult to do than a single commit.


>
> > Maybe it would be nice if proven packagers had some tooling for doing
> those
> > changes.
>
> If you will develop one, we could talk about it 
>
> [0] https://fedoraproject.org/wiki/Packaging:Guidelines#Spec_Mai
> ntenance_and_Ca
> nonicity
> >
> > clime
> >
> > On Thu, Feb 15, 2018 at 9:34 AM, Miroslav Suchý <msu...@redhat.com>
> wrote:
> >
> > > Dne 14.2.2018 v 20:41 Igor Gnatenko napsal(a):
> > > > On Wed, 2018-02-14 at 14:25 -0500, David Cantrell wrote:
> > > > > On 02/14/2018 11:44 AM, Remi Collet wrote:
> > > > > > - abuse proven packager privileges
> > > > >
> > > > > +1
> > >
> > > +1
> > >
> > > > Please, read policy[0] once more.
> > > >
> > > > > Sometimes there are situations where it's simply a lot easier to
> fix
> > >
> > > stuff
> > > > directly in Git than via bugzilla and the proper maintainers. So much
> > >
> > > easier
> > > > that we should leave this path open. These situations shouldn't arise
> > >
> > > that
> > > > often. Some examples of situations were bypassing the proper
> maintained
> > >
> > > is
> > > > considered fine:
> > > > > […]
> > > > > * small fixes or adjustments for new or modified packaging
> > > >
> > > > guidelines can be done directly in Git after being announced some
> days
> > > > in advance.
> > > >
> > > > I just missed waiting for few days (kinda intentionally), because it
> > >
> > > would not
> > > > help anyone and will just disturb maintainers to do the actual work
> > >
> > >

Re: Removal of BuildRoot

[Michal Novotny]

I feel PRs are better for this sort of stuff. Mainly because people are
informed why exactly this change is made,
they can read the guidelines and then merge the change when they are sure
they understand it. It helps spreading knowledge
and keeping community involved. Python team did it very well in their "Fedora's
Switch to Python 3 effort
", i think.

There are other reasons too. Some projects might keep the original spec
file somewhere
else than in DistGit and they need to port those changes back to the
original spec files. It is much more pleasant to have those
changes placed in a PR with a relevant description, which will also give
them a proper notification. Otherwise, they might end
up solving some unexpected conflicts next time they import their new spec
files into DistGit.

Maybe it would be nice if proven packagers had some tooling for doing those
changes.

clime

On Thu, Feb 15, 2018 at 9:34 AM, Miroslav Suchý  wrote:

> Dne 14.2.2018 v 20:41 Igor Gnatenko napsal(a):
> > On Wed, 2018-02-14 at 14:25 -0500, David Cantrell wrote:
> >> On 02/14/2018 11:44 AM, Remi Collet wrote:
> >>> - abuse proven packager privileges
> >> +1
> +1
>
> > Please, read policy[0] once more.
> >
> >> Sometimes there are situations where it's simply a lot easier to fix
> stuff
> > directly in Git than via bugzilla and the proper maintainers. So much
> easier
> > that we should leave this path open. These situations shouldn't arise
> that
> > often. Some examples of situations were bypassing the proper maintained
> is
> > considered fine:
> >> […]
> >> * small fixes or adjustments for new or modified packaging
> > guidelines can be done directly in Git after being announced some days
> > in advance.
> >
> > I just missed waiting for few days (kinda intentionally), because it
> would not
> > help anyone and will just disturb maintainers to do the actual work
> whereas it
> > doesn't make any sense because cleanup is automated.
>
> It state:
> fixes or adjustments for **new or modified** packaging guidelines
>
> This is obviously meant for changes, which would block progress. Change of
> BuildRoot tag is pretty old. It could wait
> few more days just fine.
>
>
> Miroslav
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Usefulness of `copr mock-config ` feature?

[Michal Novotny]

On Wed, Feb 14, 2018 at 11:16 AM, Pavel Raiskup <prais...@redhat.com> wrote:

> On Wednesday, February 14, 2018 10:54:48 AM CET Michal Novotny wrote:
> > Hello Pavel,
> >
> > On Wed, Feb 14, 2018 at 10:18 AM, Pavel Raiskup <prais...@redhat.com>
> wrote:
> >
> > > On Tuesday, February 13, 2018 10:15:42 PM CET Michal Novotny wrote:
> > > > On Tue, Feb 13, 2018 at 9:51 PM, Michal Novotny <cl...@redhat.com>
> > > wrote:
> > > >
> > > > > Hello,
> > > > >
> > > > > On Tue, Feb 13, 2018 at 12:54 PM, Michael Šimáček <
> msima...@redhat.com
> > > >
> > > > > wrote:
> > > > >
> > > > >> On 2018-02-13 11:47, Pavel Raiskup wrote:
> > > > >>
> > > > >>> Sorry, I wanted to CC fedora devel before, forwarding.
> > > > >>>
> > > > >>> Pavel
> > > > >>>
> > > > >>> On Tuesday, February 13, 2018 10:54:55 AM CET Pavel Raiskup
> wrote:
> > > > >>>
> > > > >>>> Because we are unable to find a consensus on implementation
> details,
> > > > >>>> it's
> > > > >>>> likely we'll drop this feature from copr API and it will be
> > > probably a
> > > > >>>> bit
> > > > >>>> more complicated to setup mock chroot for local tests in future
> > > (you'll
> > > > >>>> need to have builder machine with copr-rpmbuild installed, which
> > > brings
> > > > >>>> a
> > > > >>>> lot more runtime dependencies at least).
> > > > >>>>
> > > > >>>>  From user perspective, do you mind if we dropped `copr
> mock-config`
> > > > >>>> command?
> > > > >>>>
> > > > >>>>
> > > > >> I didn't know this command existed, but there were multiple times
> in
> > > the
> > > > >> past where I wished something like this had been available (It
> didn't
> > > exist
> > > > >> back then). It was usually situation like this: "Hi, I'm trying to
> > > build
> > > > >> $package in $copr and it fails because of $build_tool that you
> > > maintain,
> > > > >> can you help me?". And since I had no idea how his copr was set
> up,
> > > it took
> > > > >> me a lot of time before I was able to reproduce the problem. So, I
> > > would
> > > > >> find the feature useful, especially in instances outside Fedora,
> which
> > > > >> usually have more complex configurations.
> > > > >> If it had to be dropped, I'd appreciate if copr could display the
> > > > >> configuration of given project for non-owners. That way it would
> be
> > > easier
> > > > >> to construct my own config, without trying to guess stuff based on
> > > the logs.
> > > > >>
> > > > >
> > > > > First, thanks for your input. This is very useful information for
> us.
> > > > > Next, I would like to ask if it was ok to put all the functionality
> > > about
> > > > > build-testing and building itself into just a single package:
> > > > > copr-rpmbuild. I think having things on just one place can help us
> > > focus on
> > > > > doing them really well and as the copr-rpmbuild tool is already
> > > responsible
> > > > > for building, I think it would be a perfect place to add additional
> > > > > build-debugging functionality like printing-out/dumping mock
> configs,
> > > > > enablement to run just a part of the build process, possibility to
> > > enter
> > > > > the build environment interactively etc. Would this be alright?
> > > > >
> > > >
> > > > I need to add that with this tool you really need to know _what_ you
> are
> > > > building to be on the safe side. It is similar to running rpmbuild
> > > locally
> > > > (unless you are really just dumping mock configs).
> > >
> > > I use 'copr mock-config' for working with buildroot, even if I don't
> want
> > > to build anything (mock --shell).  So except from mock, any other deps
> > > installed by copr-rpmbuild are useless and I don't want them on my box
> > > basically.
> > >
> >
> > Alright, we can set some most prominent deps of copr-rpmbuild as weak
> deps.
> >
> > It will be then possible to install the minimal package setup e.g. with:
> >
> > # dnf -y install copr-rpmbuild --setopt=install_weak_deps=False
> >
> > I opened https://pagure.io/copr/copr/issue/222.
> >
> > Thanks!
>
> I wouldn't be able to install copr-rpmbuild on EPEL7 then, where I still
> can
> install mock/copr-cli and I can experiment with copr bulidroot through
> `copr
> mock-config` feature.  IOW, enforcing user to install another client tool
> for generating mock config doesn't make sense.
>

Actually, I would like to make some deps as very weak deps ('Suggests' tag),
so that they are not installed by default.

I am not sure what's the status of yum in EPEL7 but I think it would be very
nice if this functionality was backported there. If not, I will need to add
separate
Require tags for rhel. But thanks for that note!


>
> Pavel
>
>
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Usefulness of `copr mock-config ` feature?

[Michal Novotny]

Hello Pavel,

On Wed, Feb 14, 2018 at 10:18 AM, Pavel Raiskup <prais...@redhat.com> wrote:

> On Tuesday, February 13, 2018 10:15:42 PM CET Michal Novotny wrote:
> > On Tue, Feb 13, 2018 at 9:51 PM, Michal Novotny <cl...@redhat.com>
> wrote:
> >
> > > Hello,
> > >
> > > On Tue, Feb 13, 2018 at 12:54 PM, Michael Šimáček <msima...@redhat.com
> >
> > > wrote:
> > >
> > >> On 2018-02-13 11:47, Pavel Raiskup wrote:
> > >>
> > >>> Sorry, I wanted to CC fedora devel before, forwarding.
> > >>>
> > >>> Pavel
> > >>>
> > >>> On Tuesday, February 13, 2018 10:54:55 AM CET Pavel Raiskup wrote:
> > >>>
> > >>>> Because we are unable to find a consensus on implementation details,
> > >>>> it's
> > >>>> likely we'll drop this feature from copr API and it will be
> probably a
> > >>>> bit
> > >>>> more complicated to setup mock chroot for local tests in future
> (you'll
> > >>>> need to have builder machine with copr-rpmbuild installed, which
> brings
> > >>>> a
> > >>>> lot more runtime dependencies at least).
> > >>>>
> > >>>>  From user perspective, do you mind if we dropped `copr mock-config`
> > >>>> command?
> > >>>>
> > >>>>
> > >> I didn't know this command existed, but there were multiple times in
> the
> > >> past where I wished something like this had been available (It didn't
> exist
> > >> back then). It was usually situation like this: "Hi, I'm trying to
> build
> > >> $package in $copr and it fails because of $build_tool that you
> maintain,
> > >> can you help me?". And since I had no idea how his copr was set up,
> it took
> > >> me a lot of time before I was able to reproduce the problem. So, I
> would
> > >> find the feature useful, especially in instances outside Fedora, which
> > >> usually have more complex configurations.
> > >> If it had to be dropped, I'd appreciate if copr could display the
> > >> configuration of given project for non-owners. That way it would be
> easier
> > >> to construct my own config, without trying to guess stuff based on
> the logs.
> > >>
> > >
> > > First, thanks for your input. This is very useful information for us.
> > > Next, I would like to ask if it was ok to put all the functionality
> about
> > > build-testing and building itself into just a single package:
> > > copr-rpmbuild. I think having things on just one place can help us
> focus on
> > > doing them really well and as the copr-rpmbuild tool is already
> responsible
> > > for building, I think it would be a perfect place to add additional
> > > build-debugging functionality like printing-out/dumping mock configs,
> > > enablement to run just a part of the build process, possibility to
> enter
> > > the build environment interactively etc. Would this be alright?
> > >
> >
> > I need to add that with this tool you really need to know _what_ you are
> > building to be on the safe side. It is similar to running rpmbuild
> locally
> > (unless you are really just dumping mock configs).
>
> I use 'copr mock-config' for working with buildroot, even if I don't want
> to build anything (mock --shell).  So except from mock, any other deps
> installed by copr-rpmbuild are useless and I don't want them on my box
> basically.
>

Alright, we can set some most prominent deps of copr-rpmbuild as weak deps.

It will be then possible to install the minimal package setup e.g. with:

# dnf -y install copr-rpmbuild --setopt=install_weak_deps=False

I opened https://pagure.io/copr/copr/issue/222.

Thanks!


>
> Pavel
>
> > > Thank you again for your feedback
> > > Michal
> > >
> > >
> > >>
> > >> Michael
> > >> ___
> > >> copr-devel mailing list -- copr-de...@lists.fedorahosted.org
> > >> To unsubscribe send an email to copr-devel-leave@lists.
> fedorahosted.org
> > >>
> > >
> > >
>
>
>
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Usefulness of `copr mock-config ` feature?

[Michal Novotny]

On Tue, Feb 13, 2018 at 9:51 PM, Michal Novotny <cl...@redhat.com> wrote:

> Hello,
>
> On Tue, Feb 13, 2018 at 12:54 PM, Michael Šimáček <msima...@redhat.com>
> wrote:
>
>> On 2018-02-13 11:47, Pavel Raiskup wrote:
>>
>>> Sorry, I wanted to CC fedora devel before, forwarding.
>>>
>>> Pavel
>>>
>>> On Tuesday, February 13, 2018 10:54:55 AM CET Pavel Raiskup wrote:
>>>
>>>> Because we are unable to find a consensus on implementation details,
>>>> it's
>>>> likely we'll drop this feature from copr API and it will be probably a
>>>> bit
>>>> more complicated to setup mock chroot for local tests in future (you'll
>>>> need to have builder machine with copr-rpmbuild installed, which brings
>>>> a
>>>> lot more runtime dependencies at least).
>>>>
>>>>  From user perspective, do you mind if we dropped `copr mock-config`
>>>> command?
>>>>
>>>>
>> I didn't know this command existed, but there were multiple times in the
>> past where I wished something like this had been available (It didn't exist
>> back then). It was usually situation like this: "Hi, I'm trying to build
>> $package in $copr and it fails because of $build_tool that you maintain,
>> can you help me?". And since I had no idea how his copr was set up, it took
>> me a lot of time before I was able to reproduce the problem. So, I would
>> find the feature useful, especially in instances outside Fedora, which
>> usually have more complex configurations.
>> If it had to be dropped, I'd appreciate if copr could display the
>> configuration of given project for non-owners. That way it would be easier
>> to construct my own config, without trying to guess stuff based on the logs.
>>
>
> First, thanks for your input. This is very useful information for us.
> Next, I would like to ask if it was ok to put all the functionality about
> build-testing and building itself into just a single package:
> copr-rpmbuild. I think having things on just one place can help us focus on
> doing them really well and as the copr-rpmbuild tool is already responsible
> for building, I think it would be a perfect place to add additional
> build-debugging functionality like printing-out/dumping mock configs,
> enablement to run just a part of the build process, possibility to enter
> the build environment interactively etc. Would this be alright?
>

I need to add that with this tool you really need to know _what_ you are
building to be on the safe side. It is similar to running rpmbuild locally
(unless you are really just dumping mock configs).


>
> Thank you again for your feedback
> Michal
>
>
>>
>> Michael
>> ___
>> copr-devel mailing list -- copr-de...@lists.fedorahosted.org
>> To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
>>
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Usefulness of `copr mock-config ` feature?

[Michal Novotny]

Hello,

On Tue, Feb 13, 2018 at 12:54 PM, Michael Šimáček 
wrote:

> On 2018-02-13 11:47, Pavel Raiskup wrote:
>
>> Sorry, I wanted to CC fedora devel before, forwarding.
>>
>> Pavel
>>
>> On Tuesday, February 13, 2018 10:54:55 AM CET Pavel Raiskup wrote:
>>
>>> Because we are unable to find a consensus on implementation details, it's
>>> likely we'll drop this feature from copr API and it will be probably a
>>> bit
>>> more complicated to setup mock chroot for local tests in future (you'll
>>> need to have builder machine with copr-rpmbuild installed, which brings a
>>> lot more runtime dependencies at least).
>>>
>>>  From user perspective, do you mind if we dropped `copr mock-config`
>>> command?
>>>
>>>
> I didn't know this command existed, but there were multiple times in the
> past where I wished something like this had been available (It didn't exist
> back then). It was usually situation like this: "Hi, I'm trying to build
> $package in $copr and it fails because of $build_tool that you maintain,
> can you help me?". And since I had no idea how his copr was set up, it took
> me a lot of time before I was able to reproduce the problem. So, I would
> find the feature useful, especially in instances outside Fedora, which
> usually have more complex configurations.
> If it had to be dropped, I'd appreciate if copr could display the
> configuration of given project for non-owners. That way it would be easier
> to construct my own config, without trying to guess stuff based on the logs.
>

First, thanks for your input. This is very useful information for us. Next,
I would like to ask if it was ok to put all the functionality about
build-testing and building itself into just a single package:
copr-rpmbuild. I think having things on just one place can help us focus on
doing them really well and as the copr-rpmbuild tool is already responsible
for building, I think it would be a perfect place to add additional
build-debugging functionality like printing-out/dumping mock configs,
enablement to run just a part of the build process, possibility to enter
the build environment interactively etc. Would this be alright?

Thank you again for your feedback
Michal


>
> Michael
> ___
> copr-devel mailing list -- copr-de...@lists.fedorahosted.org
> To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Python2 stub packages now in EPEL stable

[Michal Novotny]

On Tue, Feb 13, 2018 at 5:32 PM, Jason L Tibbitts III 
wrote:

> [For those who don't read epel-devel, this is a duplicate of a message
> also posted there.]
>
> The initial set of stub python2-* packages I created have now made their
> way to EPEL6 and EPEL7 stable, so packages can now depend on
> python2-setuptools, python2-six, python2-pytest and python2-sphinx
> in all releases without having to add conditionals for EPEL.
>

Thank you!


>
> Feel free to suggest additional packages; I will be happy to create
> them.
>
> See https://fedoraproject.org/wiki/User:Tibbs/EPELPythonStubPackages for
> more information.
>
>  - J<
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Escaping macros in %changelog

[Michal Novotny]

I must agree with Kevin that taking every single commit message and putting
it into changelog without further tweaking
might just produce lots of redundant and not really desired lines in the
output. But I think something still can be done.
When you invoke `rpkg tag` (the same goes for `fedpkg tag`), it brings up
an editing window where you can edit a tag
message. So we could generate the commit messages into this window where
the user could edit them.
The {{{ git_change_log }}} (or just {{{ git_changelog }}}) macro would then
use exactly those tag messages
(for each tag) to generate the final change log into the spec file.

On Sat, Feb 10, 2018 at 12:54 PM, Kevin Kofler 
wrote:

> David Sommerseth wrote:
> > I doubt Koji was primarily built for "does this work?"-builds.  It exists
> > to build proper packages targeting Fedora repositories.
>
> But that is the point, to build a proper package:
>
> do {
>   try build;
> } while (!build succeeded);
>
> and the output is a working package.
>
> > To me this is backwards and is lacking some logic.  If you push things
> > which does not build properly, you also waste a build.
>
> That is a build attempt that would have had to happen anyway. Otherwise,
> how
> do I know that it doesn't build.
>
> The point is, the above optimized loop needs n build attempts. What you
> propose doing needs n+1 build attempts to get the exact same package.
>
> Kevin Kofler
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Escaping macros in %changelog

[Michal Novotny]

Hello,

On Fri, Feb 9, 2018 at 3:22 PM, Panu Matilainen  wrote:

> On 02/09/2018 03:34 PM, Josh Boyer wrote:
>
>> On Thu, Feb 8, 2018 at 1:32 PM, Matthew Miller 
>> wrote:
>>
>>> On Thu, Feb 08, 2018 at 05:02:10PM +0100, Igor Gnatenko wrote:
>>>
 It seems that a lot of people have %file, %check, %build, %whatsoever
 in their changelog section.
 Is there any reason I should not go and automatically escape them?

>>>
>>> This seems like a lot of churn. If we're going to do this, let's go big
>>> and get rid of RPM changelogs.
>>>
>>> When we have a package update, there are basically two different kinds
>>> of changelog information. Well, three.
>>>
>>> First, there's the upstream changelog. We don't generally do much with
>>> these except maybe package as %doc.
>>>
>>> Second, there's package maintainer changelogs. These are really
>>> redundant with the dist-git log. We don't really need this anymore.
>>> It's just a chore.
>>>
>>> Third, though, there's end-user information. Why should a user care
>>> *This* is redundant with bodhi update info, at least if packagers fill
>>> that out, and it often also duplicates upstream changelogs, *and* it
>>> often also covers things like "fixes CVE-' also carried the
>>> specfile changelog.
>>>
>>> This is neither most helpful for user *nor* ideal for packages. Why
>>> don't we drop changelogs entirely in favor of 1) using the dist-git
>>> logs for specfile maintainers and 2) providing the end-user information
>>> in a different way. This could be through specially formatted log lines
>>> going with the commit, or it could be simply in a standard separate
>>> file (`fedora.user-visible-changes`). Optionally, it could include both
>>> a high level end-user summary, and a detailed description for sysadmins
>>> and the curious.
>>>
>>> Wherever it lives, this would be read by Bodhi, so there's
>>> would be need to enter it more than once. And, perhaps a DNF plugin
>>> could be made to read and display this information for systems
>>> administrators.
>>>
>>
>> I fully support the removal of RPM changelogs.  However, you've missed
>> two cases:
>>
>> 1) Rawhide, which doesn't go through bodhi
>> 2) Fedora release upgrades, which don't go through bodhi
>>
>> Now, I would actually LOVE for Rawhide to go through bodhi but
>> whatever.  The release -> release upgrade isn't really solvable that
>> way though.
>>
>> Someone else suggested changelogs could be inserted during koji build
>> time.  That would be interesting to look into.
>>
>
> Koji, or fedpkg, or better yet some hook in rpm itself. It's not exactly
> rocket science we're talking about here if people are ready to give it a go.
>

I actually looked yesterday if I could make a PR for rpm implementing it
but I couldn't really find a good way to do it. So I decided to implement it
in `rpkg-client` (https://pagure.io/rpkg-client/branch/spec_preprocessor -
basically a hack upon python-rpkg library) by spec preprocessing. So,
with that development version of rpkg, you can have specs (or rather spec
templates) like this in your Git project:

Name:   {{{ git_name }}}
Version:{{{ git_version }}}
Release:1%{?dist}
Summary:This is a test package.

License:GPLv2+
URL:https://someurl.org

Source: {{{ make_source }}}

%description
This is a test package.

%prep
{{{ setup }}}

{{{ git_change_log }}}

rpkg will take that spec template and replace the {{{ ... }}} tags with
standard output of the commands inside the braces (git_name, git_version,
make_source, setup, git_change_log are all shell functions). Afterwards,
the generated spec is used to e.g. create an srpm (done by `rpkg srpm`
command).

I haven't actually implemented the `git_change_log` function yet (nor the
other functions except for `make_source`) like Igor did - currently it just
always returns '%changelog' and that's it but I wanted to show this to
possibly get some feedback.

Thank you
clime


>
> Neal, doesn't Mageia (and Mandriva) pull package changelogs from SCM
> already? Do you know what kind of hook they're using? Actually I think Suse
> does this too so Fedora is probably again the last one to adopt this...
>
> - Panu -
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: COPR + pagure + rpkg HOWTO?

[Michal Novotny]

Hello Richard,

On Sat, Feb 3, 2018 at 3:45 PM, Richard Shaw  wrote:

> I would like to manage a COPR via SCM (in this case pagure)
>
> I'm assuming using rpkg would be a good way to do this? Or should I forget
> that and just use plain git+copr-cli?
>
> There is OK documentation for the independent tools but I can't seem to
> find a HOWTO that ties it all together.
>
> I want to use my pagure project: https://pagure.io/NBEMS
>
> To tie into my COPR project: https://copr.fedorainfracloud.org/coprs/
> hobbes1069/NBEMS/
>
> so I can stop uploading package to my fedorapeople public_html site and
> build via URLs.
>

So you need to first go to "Packages" in your project, click on each
package that you want to integrate with Pagure, then at "Default Build
Source" panel, click "Edit". And pick "SCM" tab. After that
you need to insert correct values (especially for Clone URL), enable
"Webhook rebuild" and click Submit. Afterwards in your Pagure project, you
need to enable Sending Fedmsgs (in the _Hooks_ panel)
down the Setting screen. And that should be it. This is assuming that you
have the packages that you want to rebuild automatically already created by
previous srpm builds. If not, you can just create them
manually from scratch.


>
> Second question. My plan is to use this to mainly build packages for EL7
> of all the most useful applications from http://w1hkj.com for emergency
> communications on a stable and LTS platform.
>
> Some of them are already in EPEL but need newer versions of dependent
> libraries than are available to build the latest versions.
>
> I was thinking of using a git branch per application but that's not a
> typical workflow, but seems better than just using master and a bunch of
> subdirectories.
>

Yes, typically, it's just master (optionally with some other dev branches)
and bunch of subdirectories in the main repo for each subpackage. Git
branch per application will technically work as well so it's a matter of
preference.

clime


>
> Thoughts?
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Planned Outage: COPR BACKEND upgrade - 2018-01-16 09:00 UTC

[Michal Novotny]

 Planned Outage: COPR BACKEND upgrade - 2018-01-16 09:00 UTC

There will be an outage starting at 2018-01-16 09:00 UTC, which will last
approximately 0.5 hours.

To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d
'2018-01-16 09:00 UTC'

Reason for outage:

Upgrade of copr-backend machine to f27

Affected Services:

copr-backend - https://copr-be.cloud.fedoraproject.org/


Ticket Link:

https://pagure.io/fedora-infrastructure/issue/6635

Contact Information:

Please join #fedora-admin or #fedora-buildsys in irc.freenode.net or add
comments to the ticket for this outage above.
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

is there logstash alternative in Fedora?

[Michal Novotny]

Hello,

I am looking for an alternative for Java logstash application (not in
Fedora) that can parse logs (e.g. httpd access.log) and collect stats about
number of occurrences for a given search pattern (basically it can e.g.
group by IP and give number of lines for each IP and then post it to some
url address). Is there anything like this currently? I am about to
implement it but wanted to make sure I won't be doing something which
already exists.

Thank you
clime
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

COPR: usage of http:// in python client

[Michal Novotny]

Hello,

we have found out that http://copr.fedoraproject.org was used as default
API endpoint if no copr_url was specified for CoprClient initialization.
This is now fixed in the latest version of python-copr (python-copr-1.84)
and we recommend updating to that version. Also we have decided to revoke
user API tokens for which there have been accesses through the http
interface recently. You can find the list of the affected users in the
attachment and we apologize for this. Please, use
https://copr.fedorainfracloud.org/api/ to retrieve new tokens. If you know
you have been using CoprClient without specifying copr-frontend URL and you
won't find yourself in the attached list, please, go to
https://copr.fedorainfracloud.org/api/ and regenerate your tokens as well.

COPR team
jmontleon
hnakamur
user501254
sochotni
jkastner
bkabrda
james
khara
praiskup
lazka
madcat
che
openscapmaint
tartare
vishalv
jenslody
pvoborni
gozer
rholy
immanetize
msuchy
alebastr
mbaldessari
thm
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

long waiting times for COPR jobs

[Michal Novotny]

Hello,

lately, COPR pending job queues are holding jobs for pretty long time (even
hours). This is a buggy behaviour and we will be doing our best to fix this
issue in the following days.

Thank your for your patience
COPR team
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: CI projects in Copr

[Michal Novotny]

We have finished the SCM source type implementation. You can read more in
this blog post: https://clime.github.io/2017/10/24/COPR-SCM.html

Thank you for the feedback!
clime

On Wed, Sep 27, 2017 at 10:28 PM, Michal Novotny <cl...@redhat.com> wrote:

> Hello,
>
> On Tue, Sep 5, 2017 at 5:50 PM, Petr Stodulka <pstod...@redhat.com> wrote:
>
>>
>>
>> On 4.9.2017 19:27, Michal Novotny wrote:
>> > I might contact you for more information, but alright, if you feel the
>> custom script is more convenient,
>> > then I am all for it. But first, I would like to make a proposal of
>> each option (with screenshots and
>> > just complete feature request description) so that users can clearly
>> see  the options and pick what
>> > they like the best. We can work with Pavel on it.
>> >
>> > If you agree, I would post the two proposals here before actual
>> implementation.
>> >
>>
>> Yes, it would be fine see concrete proposals to discuss it before
>> implementation. Thanks.
>>
>
> in the end, we decided, we will probably try out both ways. I will likely
> implement the 'make srpm'
> command in addition to 'tito', 'tito --test', 'rpkg' options in the SCM
> tab and Pavel will make new
> source type called 'Custom' (or something similar) where user can script
> out the way how sources
> for a subsequent srpm build are going to be fetched. This script will be
> stored in DB and will
> launched in a chroot initialized by a set of predefined buildroot packages
> (i.e. fedpkg, wget,). Both
> solutions will be fairly equivalent, except in the first case the script
> will be stored in a Git repository,
> whereas in the second, it will be stored in the COPR database. The latter
> will likely offer more
> more freedom in where to fetch sources from (i.e. launchpad.net or CPAN)
> whereas the former
> will be focused mainly on Git and SVN (likely) sources.
>
> Consider this still to be in a proposal state. We will see how well the
> actual implementation goes.
>
>
>>
>> P.
>>
>>
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>>
>>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: CI projects in Copr

[Michal Novotny]

Hello,

On Tue, Sep 5, 2017 at 5:50 PM, Petr Stodulka <pstod...@redhat.com> wrote:

>
>
> On 4.9.2017 19:27, Michal Novotny wrote:
> > I might contact you for more information, but alright, if you feel the
> custom script is more convenient,
> > then I am all for it. But first, I would like to make a proposal of each
> option (with screenshots and
> > just complete feature request description) so that users can clearly
> see  the options and pick what
> > they like the best. We can work with Pavel on it.
> >
> > If you agree, I would post the two proposals here before actual
> implementation.
> >
>
> Yes, it would be fine see concrete proposals to discuss it before
> implementation. Thanks.
>

in the end, we decided, we will probably try out both ways. I will likely
implement the 'make srpm'
command in addition to 'tito', 'tito --test', 'rpkg' options in the SCM tab
and Pavel will make new
source type called 'Custom' (or something similar) where user can script
out the way how sources
for a subsequent srpm build are going to be fetched. This script will be
stored in DB and will
launched in a chroot initialized by a set of predefined buildroot packages
(i.e. fedpkg, wget,). Both
solutions will be fairly equivalent, except in the first case the script
will be stored in a Git repository,
whereas in the second, it will be stored in the COPR database. The latter
will likely offer more
more freedom in where to fetch sources from (i.e. launchpad.net or CPAN)
whereas the former
will be focused mainly on Git and SVN (likely) sources.

Consider this still to be in a proposal state. We will see how well the
actual implementation goes.


>
> P.
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: CI projects in Copr

[Michal Novotny]

On Fri, Sep 1, 2017 at 11:20 AM, Gerd Hoffmann  wrote:

>   Hi,
>
> > It's easier on implementation. That's the main reason. I generally
> > believe that
> > what's easier on implementation is better.
>
> It's maybe easier on the copr side, but not for the copr users ...
>
> If you can modify the upstream project (either because you are
> upstream, or in case upstream is willing to accept patches for copr
> support) you can just use tito and be done with it.
>
> If you can't modify upstream it starts to become difficult ...
>
> So, what would be really helpful, especially for CI with the option to
> build and test every upstream commit, would be support for *two* git
> repos.  One git repo where the spec-file and other build-related stuff
> lives (distgit like).  One git repo where the unmodified upstream
> source lives.  Updates on either repo triggers a build.  The build runs
> "git archive" on the upstream repo to generate the tarball and tweaks
> the specfile (Source and Release tags probably) before kicking off mock
> for the actual build.
>

I was additionally thinking about this and how to link the repos together.
I came to the conclusion that it would be nice to be able to put something
like this
into .spec file:

Source: https://github.com/clime/example2.git#HEAD:subpkg

That is a specific (git repo url, treeish) pair that would be git archived
by rpm itself or just an rpm pre-processor (placed in a packaging tool like
rpkg).

There already is such an option to link upstream sources:
https://fedoraproject.org/wiki/Packaging:SourceURL?rd=Packaging/SourceURL#Git_Hosting_Services
but it's not exactly the same and this could be convenient.

Wild thought here would be that the (git repo url, treeish) pair placed in
Source actually does
not need to be git archived. Instead, it could be built into an srpm (that
would probably require
additional syntax on the pair as a function application to explicitly
define type of the srpm build, e.g.:

Source: make_srpm(https://github.com/clime/example2.git#HEAD:subpkg)

In the end, the (transitively) acquired set of srpms would be collected and
built as batch build in COPR
(with results possibly placed into the same build directory).

I am not sure if there is any use-case for such a thing (probably not) but
it reminded me of what
modularity is doing (or was initially doing).


>
> cheers,
>   Gerd
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: CI projects in Copr

[Michal Novotny]

Hey, Petr

On Mon, Sep 4, 2017 at 4:27 PM, Petr Stodulka <pstod...@redhat.com> wrote:

> I apologize for late response as I was on holiday. Not sure if you already
> talked together about that but I agree with Pavel. `make srpm` solves only
> _one_
> type of troubles. I guess that usually I will get response from upstream
> like that:
>  -- we will not add Makefile just because of COPR that is not important
> for us in any way
>  -- we will not modify Makefile just because of...
>  etc.
>
> It would work for us where we are upstream, but it is just another mess
> next to _setup.py_
> for example. Really, the possibility of own script inside copr is much
> more convenient, it is
> more generic solution and covers many more troubles.
>
> Personally from my point of view, I would rather invest (e.g.) one more
> week to generic
> solution than save that time for partial solution. But I don't see into
> the COPR and I will
> not work on it so I am not saying that it has to be done in that way.
>
>
well, personally, I think the two solutions would be equivalent, while
`make srpm` would be
cleaner on API and easier to setup (the only diff would be that in the case
of srpm the
invocation would be always the same, otherwise there would be no diff).

I might contact you for more information, but alright, if you feel the
custom script is more convenient,
then I am all for it. But first, I would like to make a proposal of each
option (with screenshots and
just complete feature request description) so that users can clearly see
the options and pick what
they like the best. We can work with Pavel on it.

If you agree, I would post the two proposals here before actual
implementation.


>
>
> On 4.9.2017 09:47, Pavel Raiskup wrote:
> > On Friday, September 1, 2017 12:16:32 PM CEST Michal Novotny wrote:
> >> On Fri, Sep 1, 2017 at 8:55 AM, Marc Dequènes (Duck) <d...@redhat.com>
> >>> On 09/01/2017 01:28 AM, Michal Novotny wrote:
> >>>> But I think an off-line talk might be the best. Depends on you.
> >>>
> >>> I can understand you don't want this thread to end-up in flames, and
> yes
> >>> sometimes it helps to have a live direct talk, but this also means the
> rest
> >>> of this list is kept out. I think it would be best to improve on
> >>> collaborative talks together. Also being asked for rational may seem
> boring
> >>> but is really necessary to understand each-other and is in no way a
> >>> provocative behavior, even if Pavel seems to like teasing you :-).
> >>
> >> sure it would be good but what I would really like to see is a
> particular
> >> concrete, real-world use-case that will not work. Then it would be
> quite easy
> >> to find a solution.
> >
> > Sure, real world example [1].  There's no Makefile in the root directory
> (and I
> > don't even plan to propose adding it as that's java project, so 'make
> srpm' is
> > sort of no-go).
> >
> > We agreed with upstream on the (super-ugly btw.) directory structure
> under
> > packaging/rpm;  I hope this is one day to be replaced by trivial:
> >
> > packaging/rpm/generate-srpm.sh
> > packaging/rpm/spec.template
> >
> >> Well, we can continue discussion e.g. also in PRs if people are
> interested
> >> in this.
> >
> > Accepted, though I thought that we could s/make srpm/any command/ right
> now to
> > avoid spending additional bucks later with the PRs.  Likely, once the
> new build
> > method is added we'll maintain it forever so the bad decision is not
> completely
> > free of charge.
> >
> > [1] https://github.com/pgjdbc/pgjdbc
> >
> > Pavel
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> >
>
> --
> Petr Stodulka
> Core Services (In-place upgrades and migrations)
> IRC nicks: pstodulk, skytak
> Red Hat
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: CI projects in Copr

[Michal Novotny]

On Fri, Sep 1, 2017 at 1:41 PM, Gerd Hoffmann  wrote:

>   Hi,
>
> > Right, this is cool. The problem is that the upstream repo would need
> > to be configured to provide a public message that something has been
> > changed
> > in it (i.e. new release) so the question is how to do this part.
>
> Ah, right, setting up a webhook needs access to the upstream repo too.
>
> Add support for polling then?  Possibly at large intervals only to cap
> the resources spent on this?  Maybe once per day, so one could do
> nightly builds with this?
>

I mean, it would be possible for sure. We will see.


>
> cheers,
>   Gerd
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: CI projects in Copr

[Michal Novotny]

Hey Marc,

On Fri, Sep 1, 2017 at 8:55 AM, Marc Dequènes (Duck) <d...@redhat.com>
wrote:

> Quack,
>
> On 09/01/2017 01:28 AM, Michal Novotny wrote:
>
> > But I think an off-line talk might be the best. Depends on you.
>
> I can understand you don't want this thread to end-up in flames, and yes
> sometimes it helps to have a live direct talk, but this also means the
> rest of this list is kept out. I think it would be best to improve on
> collaborative talks together. Also being asked for rational may seem
> boring but is really necessary to understand each-other and is in no way
> a provocative behavior, even if Pavel seems to like teasing you :-).
>

sure it would be good but what I would really like to see is a particular
concrete, real-world use-case that will not work. Then it would be quite
easy
to find a solution. Otherwise it's just a matter of taste. Also the thing is
that we first need to actually make some changes in COPR code for this
to "fit-in" so we don't even need to argue now. We can wait until we have
things
ready for it.


>
> I'm really new in here, I'm only using Copr/mock-scm and besides a few
> bugs it really suit my simple needs, so I don't have any good suggestion
> myself because I don't have a clear view on the need. Nevertheless I was
> following the thread so far so I'd like to be able to continue doing so
> if I like.
>
> So if you persist on having private talks, then at least please post a
> sum-up here for the rest of the world.
>

Well, we can continue discussion e.g. also in PRs if people are interested
in this.


>
> Thanks.
> \_o<
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: CI projects in Copr

[Michal Novotny]

Hello Gerd,

On Fri, Sep 1, 2017 at 11:20 AM, Gerd Hoffmann  wrote:

>   Hi,
>
> > It's easier on implementation. That's the main reason. I generally
> > believe that
> > what's easier on implementation is better.
>
> It's maybe easier on the copr side, but not for the copr users ...
>
> If you can modify the upstream project (either because you are
> upstream, or in case upstream is willing to accept patches for copr
> support) you can just use tito and be done with it.
>
> If you can't modify upstream it starts to become difficult ...
>
> So, what would be really helpful, especially for CI with the option to
> build and test every upstream commit, would be support for *two* git
> repos.  One git repo where the spec-file and other build-related stuff
> lives (distgit like).  One git repo where the unmodified upstream
> source lives.  Updates on either repo triggers a build.  The build runs
> "git archive" on the upstream repo to generate the tarball and tweaks
> the specfile (Source and Release tags probably) before kicking off mock
> for the actual build.
>

Right, this is cool. The problem is that the upstream repo would need
to be configured to provide a public message that something has been changed
in it (i.e. new release) so the question is how to do this part. All the
rest
we could probly do with rpkg and a particular downstream repo setup.
For Pagure it would be easy because there are fedmsgs, but GitHub, GitLab
not so sure. Maybe we could ask upstream to setup a webhook. Not sure.


>
> cheers,
>   Gerd
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: CI projects in Copr

[Michal Novotny]

Hello Pavel,

On Thu, Aug 31, 2017 at 4:37 PM, Pavel Raiskup <prais...@redhat.com> wrote:

> On Thursday, August 31, 2017 3:48:21 PM CEST Michal Novotny wrote:
> > a) you need an additional db field.  you need to have more inputs in SCM
> tabs
> > when one has a meaning only if 'custom' is selected in the srpm_generator
> > select (which means you should hide/unhide that by js in frontend to
> have nice
> > user experience), then on API, you need to have one selector (const
> argument)
> > for srpm_generator and then another field (name of the script) that has
> > meaning only if 'custom' has been selected (that will occur on more
> places in
> > the code).
>
> False.  With 'make srpm' you still want to specify where the Makefile is.
> I hope you don't expect that the only-for-copr Makefiles will be added to
> the root of all the project in the wild...
>
> Anyway, I did not expected that you will complain about *one argument* in
> API or anywhere else, that's nitpick.  How expensive is that? :)  I can
> help you with this additional work, sure.
>
> > And having the selector in the first place is good because you can
> supply a
> > default value and you can implicitly point users to the well-established
> tools
> > where people can get more info about them and finally pick the tool most
> > suitable for them.
>
> Off-topic, selector picks among tito/mock-scm/py2rpm/... or
> arbitrary_script.  Each method has an arguments.
>
> > Additionally `make srpm` carries the message so user knows what's
> expected.
>
> Why do you care how the end-user names the script? :)
>
> > There also needs to be some kind of uniformity because we need to put the
> > output srpm into the predefined place (git repo directory) and also such
> > scripts would usually tend to have similar names (gen_srpm.py,
> make_srpm.pl),
> > so automatically it is good to have a predefined choice, I mean...why
> not.
>
> How the "name of the generating tool" reflects where the result SRPM is
> put, and how "copr is going to import that"?
>
> > You can call your any_script.xyz from the Makefile.
>
> No, I __have to__, and that's the difference :)  What's the benefit on
> enforcing it?
>
> > Everyone is familar with Makefiles and likes them (for simple things at
> > least).
>
> (rofl) I wish this was truth.
>
> > It's a nice tradition.  And the approach is the same thing as defining a
> > callback method that is being called from a certain lib that goes back
> to your
> > code.
> >
> > b) I like Makefiles for simple things, I think it's a neat choice. Also I
> > hope that the default choice ('rpkg') will serve pretty well.
>
> I like Makefiles too, but that's not about my/your preferences.
>
> Yes, let's have rpkg/tito/mock-scm/xxx2rpm/.. methods to obtain sources,
> but
> let's have also a fall-back option which matches everybody else.  After
> some time, we'll see how the fall-back is useful (and whether anybody
> still uses other declarative and not-flexible methods...).
>
> > c) Note that you can cover your use-case (of any-name script) by simply
> > calling that script by name from the Makefile if you want. So there is
> nothing
> > to be refactored.
>
> Will ninja people install some Makefile only because of CI in Copr?  So
> you either will be adding ninja support (mistake), or you replace the
> "make srpm" build option with general one (api change that annoys users).
> That's the refactoring I'm talking about.
>
> Thanks,
> Pavel
>

Please, let's have an off-line talk. I think I can better clarify why I
think `make srpm`
is the best. It's mostly about where we are now and where we need to get.

Or if there is a concrete use-case that you know that will break, please
tell, so that
we can find a solution immediately.

But I think an off-line talk might be the best. Depends on you.


>
> > >Ok, even better -> allow specifying custom command, like:
> >
> > >Git Repo:
> > >something.somewhere.git/project/foo
> > >Command to get sources:
> > cd packaging/rpm/fedora ; SOMEVAR=something ./generate-rpm.sh
> --some-arg
> > >Packages needed to obtain sources:
> > help2man, gettext-devel, wget, git-lfs
> > >SRPM pattern:
> > packaging/rpm/fedora/xyz*.src.rpm
> >
> > >The pattern is important;  plus we should declare that only the first
> > matched
> > >srpm is going to be built.
> >
> > This is already _very_ complicated at least for new users that we would
> > also like
> > to attract (in addition to satisfying power us

Re: CI projects in Copr

[Michal Novotny]

On Thu, Aug 31, 2017 at 1:47 PM, Pavel Raiskup <prais...@redhat.com> wrote:

> On Thursday, August 31, 2017 11:43:08 AM CEST Michal Novotny wrote:
> > On Thu, Aug 31, 2017 at 8:43 AM, Pavel Raiskup <prais...@redhat.com>
> wrote:
> > > I'm curious why you insist on 'make srpm';  that sounds like you try
> to push
> > > the copr users somewhere, to "standardize something".
> >
> > It's easier on implementation. That's the main reason. I generally
> believe
> > that what's easier on implementation is better.
>
> This is not first time we talk about this...
>
> (a) can you elaborate what's "easier" to implement on the 'make srpm' way?
>
> (b) shouldn't you make a life easier to your users?  Even when I really
> like
> make, what's easier on "enforcing" Makefile existence to be able to
> enable CI in copr?
>
> (c) Wrong general belief, please, forget about that.  Doing it wrong (== an
> "easier" way) in the beginning is much more expensive in the end (try
> to
> grep for "refactor" word...).  The proposal is to have "one method"
> which suits everybody; and never touch it again.  But yeah, no-thanks
> for
> not listening.  Again.
>

a) you need an additional db field. you need to have more inputs in SCM
tabs when
one has a meaning only if 'custom' is selected in the srpm_generator select
(which
means you should hide/unhide that by js in frontend to have nice user
experience),
then on API, you need to have one selector (const argument) for
srpm_generator
and then another field (name of the script) that has meaning only if
'custom' has
been selected (that will occur on more places in the code). And having the
selector
in the first place is good because you can supply a default value and you
can implicitly point
users to the well-established tools where people can get more info about
them
and finally pick the tool most suitable for them. Additionally `make srpm`
carries the message
so user knows what's expected. There also needs to be some kind of
uniformity
because we need to put the output srpm into the predefined place (git repo
directory)
and also such scripts would usually tend to have similar names
(gen_srpm.py, make_srpm.pl),
so automatically it is good to have a predefined choice, I mean...why not.
You can call
your any_script.xyz from the Makefile. Everyone is familar with Makefiles
and likes them
(for simple things at least). It's a nice tradition. And the approach is
the same thing as defining a
callback method that is being called from a certain lib that goes back to
your code.

b) I like Makefiles for simple things, I think it's a neat choice. Also I
hope that the default
choice ('rpkg') will serve pretty well.

c) Note that you can cover your use-case (of any-name script) by simply
calling
that script by name from the Makefile if you want. So there is nothing to
be refactored.

>Ok, even better -> allow specifying custom command, like:

>Git Repo:
>something.somewhere.git/project/foo
>Command to get sources:
cd packaging/rpm/fedora ; SOMEVAR=something ./generate-rpm.sh --some-arg
>Packages needed to obtain sources:
help2man, gettext-devel, wget, git-lfs
>SRPM pattern:
packaging/rpm/fedora/xyz*.src.rpm

>The pattern is important;  plus we should declare that only the first
matched
>srpm is going to be built.

This is already _very_ complicated at least for new users that we would
also like
to attract (in addition to satisfying power users).

So these are my reasons. I am willing to discuss this but at the same time
I don't
want to spend too much time on this because it really is an implementation
detail.

| Pavel

On Thu, Aug 31, 2017 at 1:47 PM, Pavel Raiskup <prais...@redhat.com> wrote:

> On Thursday, August 31, 2017 11:43:08 AM CEST Michal Novotny wrote:
> > On Thu, Aug 31, 2017 at 8:43 AM, Pavel Raiskup <prais...@redhat.com>
> wrote:
> > > I'm curious why you insist on 'make srpm';  that sounds like you try
> to push
> > > the copr users somewhere, to "standardize something".
> >
> > It's easier on implementation. That's the main reason. I generally
> believe
> > that what's easier on implementation is better.
>
> This is not first time we talk about this...
>
> (a) can you elaborate what's "easier" to implement on the 'make srpm' way?
>
> (b) shouldn't you make a life easier to your users?  Even when I really
> like
> make, what's easier on "enforcing" Makefile existence to be able to
> enable CI in copr?
>
> (c) Wrong general belief, please, forget about that.  Doing it wrong (== an
> "easier" way) in the beginning is much more expensive in the end (try
> to
> grep for "refactor" word...).  The proposal is to have "one method"
> which suits everybody; and never touch it again.  But yeah, no-thanks
> for
> not listening.  Again.
>
> Pavel
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: CI projects in Copr

[Michal Novotny]

On Thu, Aug 31, 2017 at 8:43 AM, Pavel Raiskup <prais...@redhat.com> wrote:

> On Wednesday, August 30, 2017 5:18:39 PM CEST Michal Novotny wrote:
> > We are considering the options here and so far the most convenient
> method (at
> > least from the implementation point of view) seems to be to
> automatically call
> > `make srpm` command in the source git repo if user selects `make srpm`
> as a
> > srpm generator method
>
> I'm curious why you insist on 'make srpm';  that sounds like you try to
> push the
> copr users somewhere, to "standardize something".
>
>
It's easier on implementation. That's the main reason. I generally believe
that
what's easier on implementation is better.


> Please allow specifying custom script, relatively placed in the git
> repository.
> That's exactly the same thing, but users don't have to create Makefile
> "because
> copr ..." -- users just can use what they already have.
>
> > for his (or her) SCM project (this will be a select
> > field in UI and also it will be a build parameter available in our future
> > API). That means it would be a custom script
> > placed inside a Makefile under srpm goal. Custom packages needed for this
> > operation could be
> > specified in minimal buildroot of the given chroot (in chroot settings).
> >
> > We will probably also add a field to differentiate between srpm buildroot
> > packages and rpm buildroot packages and also make this setting available
> > across all project chroots.
>
> Thanks for this!
>
> Pavel
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: CI projects in Copr

[Michal Novotny]

Hello Martin,

On Wed, Aug 23, 2017 at 2:02 PM, Martin Sehnoutka 
wrote:

> Hi,
>
> I'm using Copr for build on commit for dnssec-trigger project:
> https://github.com/InfrastructureServices/dnssec-trigger-fedora
> It's using tito.
>
> But I'm looking for a different way of doing this. Especially when I
> work on some upstream project and I don't want to force them to include
> tito. Anyway I didn't have time to check other possible solutions to
> this problem.
>

Thanks for such a great feedback. We would like to provide several options
for srpm generation out of a SCM (Git/SVN) repo: tito, rpkg, and custom
(where custom could be done by e.g. calling `make srpm` command in
the repo). Both rpkg and custom will be very "light-weight". rpkg will need
.spec file present in the repository, with "custom" you can do anything
you want. We should have this solution quite soon so I can keep you
informed.


>
> Regards,
> Martin
>
> On 08/23/2017 01:46 PM, Miroslav Suchý wrote:
> > Hi,
> > I am gathering informations about various use of CI with Copr. Do you
> > use Copr for building packages for nightlies? For building packages
> > before pull request is merged? Do you have your set up described
> > somewhere? What is the name of your project?
> >
> > Please let me know. Either here or via private reply.
> > It will help me to understand your use of Copr and to make Copr better.
> >
> > Thanks in advance.
> >
> > Miroslav Suchy
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
> --
> Martin Sehnoutka | Associate Software Engineer
> PGP: 5FD64AF5
> UTC+1 (CET)
> RED HAT | TRIED. TESTED. TRUSTED.
>
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: CI projects in Copr

[Michal Novotny]

Hello Petr,

On Thu, Aug 24, 2017 at 1:35 PM, Petr Stodulka  wrote:

>
>
> On 24.8.2017 08:04, Pavel Raiskup wrote:
> > On Wednesday, August 23, 2017 1:46:46 PM CEST Miroslav Suchý wrote:
> >> Do you use Copr for building packages for nightlies? For building
> packages
> >> before pull request is merged?
> >
> > Yes, not particulary me -- but I helped to guys in pgjdbc project to
> setup CI:
> >
> > https://copr.fedorainfracloud.org/coprs/g/pgjdbc/pgjdbc-travis/
> > https://github.com/pgjdbc/pgjdbc/blob/master/packaging/
> rpm/fedora-image/copr-ci-git
> >
> >> Do you have your set up described somewhere?
> >
> > No, since it is too complicated.  Tito is a burden for distro-agnostic
> upstream.
> >
> > Since upstream had travis-ci already enabled, my plan was to generate
> src.rpm in
> > travis-ci and submit build into copr (together with other CI tasks).
> >
> > Two major problems:
> > 1. Travis is (or was that time) debian/ubuntu only, so it is actually
> not very
> >convenient to install all the necessary tooling there;  so the
> work-around
> >was to use Fedora docker-image and that image is pulled in for each
> CI run.
> >
> > 2. You need to store your copr credentials into git.  You can cipher
> that, but
> >at least it is not convenient to store *your own* copr authentication
> token
> >into git repo, because always at least other git committers can
> decipher it.
> >You also need to re-generate your API token twice a year (it means
> you need
> >to bother the upstream with "useless" commits, but the worst thing is
> that
> >you need to regularly go back and pay attention to fixing the CI).
> >
> > Being able to specify (a) scm repo, (b) build deps and (c) any (turing
> complete)
> > script within the git repo (to generate the sources) would make setting
> up the
> > CI a trivial task.
>
> +1
>
> That is something that could help us definitely too. Nowadays we have
> scripts for
> packaging in Jenkins, that run tests and prepare SRPM for the COPR, that
> requires
> in addition changes in upstream repository itself (e.g. public spec file
> as part
> of the repository). More convenient would be (not only for our team, but
> for me too
> as packager)
>
> a) option to provide script in COPR, that will prepare sources, patches,
> modified SPEC file, ... on the COPR side. The script would be processed
> for example
> when I sent request to COPR for specific repository, with whatever data
> that will
> be processed by the script (e.g. commit hash, branch, PR number).
>
> b) store the specfile into the COPR repository, so it could be used by the
> script
>and it will not be required to be part of the upstream repository
> (usually the
>SPEC is not part of the upstream repo or we want different spec than
> upstream
>provides)
>
> I found now that in COPR is something that b) describes, but I am not sure
> that
> it is same. Still, own script that would prepare sources for COPR builds
> is the
> most missing feature for me.
>
>
We are considering the options here and so far the most convenient method
(at least
from the implementation point of view) seems to be to automatically call
`make srpm`
command in the source git repo if user selects `make srpm` as a srpm
generator
method for his (or her) SCM project (this will be a select field in UI and
also it will be
a build parameter available in our future API). That means it would be a
custom script
placed inside a Makefile under srpm goal. Custom packages needed for this
operation could be
specified in minimal buildroot of the given chroot (in chroot settings). We
will probably
also add a field to differentiate between srpm buildroot packages and rpm
buildroot packages
and also make this setting available across all project chroots.

Would this cover and satisfy your needs? I would personally really like if
we made it
possible for you to use COPR solely. COPR will soon become _very_ powerful
tool.

>
> >
> > Pavel
> >
> >> What is the name of your
> >> project?
> >>
> >> Please let me know. Either here or via private reply.
> >> It will help me to understand your use of Copr and to make Copr better.
> >>
> >> Thanks in advance.
> >>
> >> Miroslav Suchy
> >> ___
> >> devel mailing list -- devel@lists.fedoraproject.org
> >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> >>
> >
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> >
>
> --
> Petr Stodulka
> Core Services (In-place upgrades and migrations)
> IRC nicks: pstodulk, skytak
> Red Hat
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
>
___
devel mailing list -- 

Re: COPR strategy

[Michal Novotny]

Hello Rudolf,

On Thu, Aug 24, 2017 at 4:10 AM, Rudolf Kastl <che...@gmail.com> wrote:

> Hey,
>
> I am currently maintaining llvm trunk and mesa git snapshot repos for f25
> and f26 at: https://copr.fedorainfracloud.org/coprs/che.
>
> One thing i would love to see is the ability to have a buildrepo and a
> release repo and beeing able to sync from build to release once a complete
> buildchain successfully built.
>
> More thorough description of the problem and a possible solution:
>
> * you have a dependency chain of 3 packages to build
> * you need to regen repos after each package because the next package in
> the tree depends on the first one. (like clang on llvm)
> * then after building the first 2 packages the 3rd package breaks ... you
> end up with a broken dep chain in the repo.
>
> Now a workaround would be to do scratch builds first and then final repo
> builds. But e.g. for llvm (only the llvm library) that means... over 100
> minutes buildtime using 4 builders (32bit / 64bit for 2 distro versions).
>
> What i would love to see is to be able to build in one repository and then
> send (copy/rsync whatever) the built chain over to a release repository.
> This way also testing is possible before pushing the stuff to consumers.
>
>
So, this is interesting. This is something like auto-forking from one
project to another after a successful batch build (under development). It
actually could work just inside one project if the batch building would be
done separately from the main project repo and only be included if
successful. Ok, thanks for this input. I think we can do something about
this.


> kind regards,
> Rudolf Kastl
>
>
>
> 2017-08-22 17:15 GMT+02:00 Kamil Dudka <kdu...@redhat.com>:
>
>> On Tuesday, August 22, 2017 5:03:06 PM CEST Michal Novotny wrote:
>> > On Tue, Aug 22, 2017 at 4:40 PM, Kamil Dudka <kdu...@redhat.com> wrote:
>> > > On Tuesday, August 22, 2017 1:51:44 PM CEST Michal Novotny wrote:
>> > > > Hey Kamil,
>> > > >
>> > > > On Tue, Aug 22, 2017 at 12:07 PM, Kamil Dudka <kdu...@redhat.com>
>> wrote:
>> > > > > On Tuesday, August 22, 2017 9:04:24 AM CEST Matthias Runge wrote:
>> > > > > > - the ability to directly upload srpms; that is, one can store
>> spec
>> > > > > >
>> > > > > >   files etc. on the local machine. I'm undecided, if
>> integrating a
>> > > > > >   distgit on copr would solve any issues or would introduce
>> more,
>> > >
>> > > like
>> > >
>> > > > > >   diverging specs.
>> > > > >
>> > > > > Building packages from dist-git is already possible via 'copr
>> > > > > buildfedpkg'.
>> > > > > The problem is that the last time I tried, it only worked for the
>> > >
>> > > official
>> > >
>> > > > > Fedora branches.  All attempts to build something from a
>> > >
>> > > private-kdudka-*
>> > >
>> > > > > branch failed with the well known "Could not find the dist from
>> branch
>> > > > > name"
>> > > > > failure of fedpkg.  Unless arbitrary dist-git branches are
>> suported,
>> > >
>> > > the
>> > >
>> > > > > 'copr buildfedpkg' command is pretty useless.
>> > > >
>> > > > Actually, we already support arbitrary dist-git branches in COPR
>> > >
>> > > Sounds good.  I wanted to check this:
>> > >
>> > > % copr buildfedpkg --branch private-kdudka-libcurl-nss --clone-url
>> > > https://src.fedoraproject.org/rpms/curl.git kdudka/tmp
>> > >
>> > > Build was added to tmp:
>> > >   https://copr.fedorainfracloud.org/coprs/build/592748/
>> > >
>> > > Created builds: 592748
>> > > Watching build(s): (this may be safely interrupted)
>> > >
>> > >   16:20:56 Build 592748: importing
>> > >
>> > > But the task hangs indefinitely in the "importing" state.  You can see
>> > > that
>> > > http://copr-dist-git.fedorainfracloud.org/per-task-logs/592748.log
>> still
>> > > grows with obvious periodicity.
>> > >
>> > > Am I doing anything wrong?
>> >
>> > Uh, not really. fedpkg was not installed on the production machine thus
>> the
>> > import was failing.
>> > Note that th

Re: modularity: (my) expectations vs. reality

[Michal Novotny]

Hello Langdon,

On Tue, Aug 22, 2017 at 11:42 PM, Langdon White <lang...@fedoraproject.org>
wrote:

>
>
> On Tue, Aug 22, 2017 at 2:40 PM Michal Novotny <cl...@redhat.com> wrote:
>
>> I would like to publicly note that I had completely different idea about
>> this project first time I have encountered it at the last Flock.
>>
>> My idea was that the project will target runtime rather than build-time
>> and will try to provide a set of packages that would be able to
>> e.g. spawn and run an httpd stack almost at one command.
>>
>> So that we will basically have e.g. this functionality:
>> https://hub.docker.com/r/p0bailey/docker-flask/ but integrated directly
>> in
>> distribution.
>>
>> This would make lots of sense to me because it would work similarly to
>> how upstream projects get
>> into Fedora (and RHEL) eventually. They need to pass certain criteria for
>> being accepted and then
>> there is is a group of people that maintains it in the given operating
>> system.
>>
>> Similarly for the modularity (as I saw it), there would be e.g. a docker
>> image that would slowly make
>> it into being a full-fledged system component that can be run in a
>> container or even natively on the host.
>>
>> The concrete implementation would probably include ansible where the
>> modules (being standard rpms)
>> would together make a big ansible playbook archive (e.g. placed under
>> /etc/playbook) that would include
>> default templates describing default sysadmin use-cases (like importing
>> db and web application start)
>> that could be overridden by a custom user template being placed at the
>> same subpath under e.g. /etc/custom-playbook.
>>
>> This would be a killer tool for sysadmins that could script their common
>> use-cases in a simple manner and completely
>> avoid any nerve-wrecking direct config manipulations on a running system
>> that (almost) each of us is familiar with. It would actually be
>> a common sysadmin (and power-user) language on RHEL based distros and I
>> think you can imagine this can be pretty cool.
>>
>> This approach would be also very flexible because you could define your
>> resources that you want to launch individual module
>> components on by altering a default resource setup and switch from
>> spawning everything natively to spawning everything in docker
>> containers locally to spawning everything in docker containers in
>> OpenShift staging instance to spawning everything in OpenShift production
>> instance.
>>
>> This also makes lots of sense from the human-effort point of view. We
>> could apply very well our sysadmin expertise in a certain
>> areas and transmit it directly to our users through code that we would
>> have written. Packagers would be config masters and they
>> would maintain default configuration to provide user with the most
>> effortless way to make something run (e.g. dovecot + postfix combo).
>>
>> And we could then also maintain custom playbooks for specific customers
>> meaning we would be able to create system cut directly to
>> their needs and have means to maintain it at large scales. And this would
>> basically mean having an rpm somewhere being named after
>> our customer e.g. mailserver-intel with a set of specific intel
>> mailserver ansible playbooks.
>>
>> After time I started to understand that the focus of modularity is
>> different and it rather focuses on having tight control over
>> the build process and lifecycle syncing across different system
>> components.
>>
>> I am not saying this is wrong or anything. It probably just means I was
>> mislead in my expectations but still I would like to share this
>> particular point of view as it makes lots of sense to me and it is
>> something that makes me excited.
>>
>> Sorry for not being technical or anything. You can consider this to be a
>> short story that doesn't deserve much attention.
>> clime
>>
>> ...Oh yeah, I started very basic PoC at https://pagure.io/lamp and
>> needed to postpone it a bit. It might be worth continuing
>>
>
> So.. in short, I think this is a cool idea. Also, I think this is the kind
> of thing that modularity could enable.
>

The question is if this isn't already enabled.


> We had in the game plan, way back, allowing super sophisticated "post
> install scripts" as part of the install profile concept. Basically, we had
> the idea that you could have an ansible playbook as part of the install
> profile. However, it is just on the "someday&quo

modularity: (my) expectations vs. reality

[Michal Novotny]

I would like to publicly note that I had completely different idea about
this project first time I have encountered it at the last Flock.

My idea was that the project will target runtime rather than build-time and
will try to provide a set of packages that would be able to
e.g. spawn and run an httpd stack almost at one command.

So that we will basically have e.g. this functionality:
https://hub.docker.com/r/p0bailey/docker-flask/ but integrated directly in
distribution.

This would make lots of sense to me because it would work similarly to how
upstream projects get
into Fedora (and RHEL) eventually. They need to pass certain criteria for
being accepted and then
there is is a group of people that maintains it in the given operating
system.

Similarly for the modularity (as I saw it), there would be e.g. a docker
image that would slowly make
it into being a full-fledged system component that can be run in a
container or even natively on the host.

The concrete implementation would probably include ansible where the
modules (being standard rpms)
would together make a big ansible playbook archive (e.g. placed under
/etc/playbook) that would include
default templates describing default sysadmin use-cases (like importing db
and web application start)
that could be overridden by a custom user template being placed at the same
subpath under e.g. /etc/custom-playbook.

This would be a killer tool for sysadmins that could script their common
use-cases in a simple manner and completely
avoid any nerve-wrecking direct config manipulations on a running system
that (almost) each of us is familiar with. It would actually be
a common sysadmin (and power-user) language on RHEL based distros and I
think you can imagine this can be pretty cool.

This approach would be also very flexible because you could define your
resources that you want to launch individual module
components on by altering a default resource setup and switch from spawning
everything natively to spawning everything in docker
containers locally to spawning everything in docker containers in OpenShift
staging instance to spawning everything in OpenShift production instance.

This also makes lots of sense from the human-effort point of view. We could
apply very well our sysadmin expertise in a certain
areas and transmit it directly to our users through code that we would have
written. Packagers would be config masters and they
would maintain default configuration to provide user with the most
effortless way to make something run (e.g. dovecot + postfix combo).

And we could then also maintain custom playbooks for specific customers
meaning we would be able to create system cut directly to
their needs and have means to maintain it at large scales. And this would
basically mean having an rpm somewhere being named after
our customer e.g. mailserver-intel with a set of specific intel mailserver
ansible playbooks.

After time I started to understand that the focus of modularity is
different and it rather focuses on having tight control over
the build process and lifecycle syncing across different system components.

I am not saying this is wrong or anything. It probably just means I was
mislead in my expectations but still I would like to share this
particular point of view as it makes lots of sense to me and it is
something that makes me excited.

Sorry for not being technical or anything. You can consider this to be a
short story that doesn't deserve much attention.
clime

...Oh yeah, I started very basic PoC at https://pagure.io/lamp and needed
to postpone it a bit. It might be worth continuing
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: COPR strategy

[Michal Novotny]

On Tue, Aug 22, 2017 at 4:40 PM, Kamil Dudka <kdu...@redhat.com> wrote:

> On Tuesday, August 22, 2017 1:51:44 PM CEST Michal Novotny wrote:
> > Hey Kamil,
> >
> > On Tue, Aug 22, 2017 at 12:07 PM, Kamil Dudka <kdu...@redhat.com> wrote:
> > > On Tuesday, August 22, 2017 9:04:24 AM CEST Matthias Runge wrote:
> > > > - the ability to directly upload srpms; that is, one can store spec
> > > >
> > > >   files etc. on the local machine. I'm undecided, if integrating a
> > > >   distgit on copr would solve any issues or would introduce more,
> like
> > > >   diverging specs.
> > >
> > > Building packages from dist-git is already possible via 'copr
> > > buildfedpkg'.
> > > The problem is that the last time I tried, it only worked for the
> official
> > > Fedora branches.  All attempts to build something from a
> private-kdudka-*
> > > branch failed with the well known "Could not find the dist from branch
> > > name"
> > > failure of fedpkg.  Unless arbitrary dist-git branches are suported,
> the
> > > 'copr buildfedpkg' command is pretty useless.
> >
> > Actually, we already support arbitrary dist-git branches in COPR
>
> Sounds good.  I wanted to check this:
>
> % copr buildfedpkg --branch private-kdudka-libcurl-nss --clone-url
> https://src.fedoraproject.org/rpms/curl.git kdudka/tmp
> Build was added to tmp:
>   https://copr.fedorainfracloud.org/coprs/build/592748/
> Created builds: 592748
> Watching build(s): (this may be safely interrupted)
>   16:20:56 Build 592748: importing
>
> But the task hangs indefinitely in the "importing" state.  You can see that
> http://copr-dist-git.fedorainfracloud.org/per-task-logs/592748.log still
> grows with obvious periodicity.
>
> Am I doing anything wrong?
>


Uh, not really. fedpkg was not installed on the production machine thus the
import was failing.
Note that this is still slightly under development but it should definitely
work as a feature in
any case.



>
> Kamil
>
> > and we also aim
> > to be able to build from any dist-git (at least being based on
> > https://src.fedoraproject.org/rpms/dist-git).
> >
> > Currently we also support building from copr-dist-git in addition to
> Fedora
> > DistGit but
> > we need to reflect that in our API and in copr-cli interface by renaming
> > the subcommand.
> > (or providing the new generic one while keeping the old one for some
> time)
> >
> > Then there is actually also the new rpkg client (based on pyrpkg lib):
> > https://src.fedoraproject.org/rpms/rpkg-client
> > that you can use for launching COPR builds from any dist-git repo being
> > locally checked out.
> >
> > > Kamil
> > > ___
> > > devel mailing list -- devel@lists.fedoraproject.org
> > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: f27 builds in COPR fail without logs

[Michal Novotny]

Eventually, a new version should pop up here:
https://bodhi.fedoraproject.org/updates/?packages=mock

You can give it Karma when it appears so that it reaches Fedora repos a bit
faster.

On Tue, Aug 22, 2017 at 2:41 PM, Alexander Ploumistos <
alex.ploumis...@gmail.com> wrote:

> Thanks Michal. Is there someplace I should monitor to know when the
> f27 mock will be available?
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: New copr-frontend release

[Michal Novotny]

Hey Kevin,

On Tue, Aug 22, 2017 at 2:03 PM, Kevin Kofler <kevin.kof...@chello.at>
wrote:

> Michal Novotny wrote:
> >   - Batch package rebuilding ("Rebuild all" button in Packages view) so
> > that you can rebuild all your packages in the new chroots.
>
> Unfortunately, this feature is less useful than I had expected, it does not
> work for uploaded SRPMs or SRPMs fetched from URLs. In that case, I would
> have expected it to just copy the dist-git contents from the build that is
> being rebuilt (even for the URL case, I would not expect it to try to
> refetch the URL, which may no longer be valid). Instead, I got an error
> message that it does not have any sources to fetch.
>

It actually works like you expect for uploaded SRPMs and URL SRPMs.
For both these build types, imported copr-dist-git sources are being used.
This will be a bug somewhere else. You can contact me personally or here
with the details.

I ended up passing the output SRPMs of the Copr builds as the SRPM URLs for
> new builds as a workaround.
>
> (I prefer the automatic forking option, but unfortunately, the F26
> branching
> happened before it was introduced, so it used the old model, where rawhide
> was renamed to f26 and the rawhide chroot started up empty. So I had to do
> rebuilds for Rawhide.)
>
> Kevin Kofler
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: COPR strategy

[Michal Novotny]

Hey Kamil,

On Tue, Aug 22, 2017 at 12:07 PM, Kamil Dudka  wrote:

> On Tuesday, August 22, 2017 9:04:24 AM CEST Matthias Runge wrote:
> > - the ability to directly upload srpms; that is, one can store spec
> >   files etc. on the local machine. I'm undecided, if integrating a
> >   distgit on copr would solve any issues or would introduce more, like
> >   diverging specs.
>
> Building packages from dist-git is already possible via 'copr buildfedpkg'.
> The problem is that the last time I tried, it only worked for the official
> Fedora branches.  All attempts to build something from a private-kdudka-*
> branch failed with the well known "Could not find the dist from branch
> name"
> failure of fedpkg.  Unless arbitrary dist-git branches are suported, the
> 'copr buildfedpkg' command is pretty useless.
>

Actually, we already support arbitrary dist-git branches in COPR and we
also aim
to be able to build from any dist-git (at least being based on
https://src.fedoraproject.org/rpms/dist-git).

Currently we also support building from copr-dist-git in addition to Fedora
DistGit but
we need to reflect that in our API and in copr-cli interface by renaming
the subcommand.
(or providing the new generic one while keeping the old one for some time)

Then there is actually also the new rpkg client (based on pyrpkg lib):
https://src.fedoraproject.org/rpms/rpkg-client
that you can use for launching COPR builds from any dist-git repo being
locally checked out.


>
> Kamil
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: COPR strategy

[Michal Novotny]

Hello Mikolaj,

On Tue, Aug 22, 2017 at 11:29 AM, Mikolaj Izdebski <mizde...@redhat.com>
wrote:

> On 08/22/2017 11:17 AM, Michal Novotny wrote:
> >> - it would be great, if there is a possibility to trigger rebuilds on
> >>   dependent packages, like rebuild required packages after ABI bump.
> >>
> >
> > Right, this would be a nice option. I could imagine this being
> implemented
> > as a configurable fedmsg listener that would launch rebuilds on certain
> > events
> > like bumps of certain packages, branching event, and possibly others.
>
> This is implemented by Koschei. Not enabled until at least Copr frontend
> completes RFR process. I can enable it in staging sooner, provided that
> Koschei can get Copr credentials for authenticating through its API.
>
>
This would be cool! I am looking forward to exploring this.


>
> --
> Mikolaj Izdebski
> Software Engineer, Red Hat
> IRC: mizdebsk
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: f27 builds in COPR fail without logs

[Michal Novotny]

Hello Alexander,

you haven't missed anything. It is just that there hasn't been mock release
yet
with f27 configs added. It is in upstream already but not yet released. If
it is
not in Fedora until the end of the week, then we can probably temporarily
provide
our own substitute repo configs.

clime

On Tue, Aug 22, 2017 at 12:33 PM, Alexander Ploumistos <
alex.ploumis...@gmail.com> wrote:

> Hello,
>
> For the past hour or so, I've been trying to rebuild my copr packages
> for f27 and rawhide. While there were some hiccups with rawhide, e.g.
> not finding mirrors to download packages, after resubmitting them a
> couple of times, all builds were successful. On the other hand, f27
> builds fail as soon as the source rpm gets imported and there are no
> logs to give a clue as to what is happening.
>
> For example, take a look at this attempt:
> https://copr.fedorainfracloud.org/coprs/alexpl/scidavis/build/592629/
>
> There aren't many recent f27 builds listed in copr at the moment, but
> those that are listed, have also failed without any logs:
> https://copr.fedorainfracloud.org/coprs/g/dnsoarc/dnscap-pr/build/592604/
> https://copr.fedorainfracloud.org/coprs/g/dnsoarc/drool-pr/build/592607/
>
> Have I missed something?
>
> Regards
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: COPR strategy

[Michal Novotny]

Hello Matthias,

On Tue, Aug 22, 2017 at 9:04 AM, Matthias Runge <mru...@matthias-runge.de>
wrote:

> On Tue, Aug 22, 2017 at 05:17:56AM +0200, Michal Novotny wrote:
> > Hello,
> >
> > we will have soon a planning meeting that should determine a more
> long-term
> > strategy and bring us to a team agreement on what COPR currently is and
> > what it should be in half a year or so.
> >
> > I would like to kindly ask for some input here on the devel list to find
> > out what the actual expectations of COPR are and if there are any ideas
> > about what could COPR bring to the game.
>
> So, as a starter, what I really like about copr is:
>
> - it is actually a incubator, a tool to get packages or collections of
>   packages built. One can easily experiment without actually disturbing
>   other users. Copr lowers the entry barrier for new pacakgers.
>
> - the ability to directly upload srpms; that is, one can store spec
>   files etc. on the local machine. I'm undecided, if integrating a
>   distgit on copr would solve any issues or would introduce more, like
>   diverging specs.
>
> - the ability to include external repositories, like the one from CentOS
>   project.
>
>
Thanks! Good to hear what features are appreciated.



> What I would like to see:
>
> - maybe a easy possibility to build packages triggered by upstream
>   source changes. This is comparable to delorean[1]. I'm not sure if it
>   needs to be re-implemented.
>

We actually have this possibility implemented through SCM-1 and SCM-2
source types and webhook mechanism.


> - prioritization of manually uploaded tasks vs. automatic builds. If
>   that really lowers the waiting time for builds it to be discussed.
>   Maybe adding a "bulk" flag to tag builds as: build it, when a builder
>   is available, but it's not a priority. Send a message once the build
>   is done.
>

We have added --background tag which is very similar to --bulk tag you
are suggesting. It's a user option (choice) to tag a build like this if he
or she
wants to.


>
> - it would be great, if there is a possibility to trigger rebuilds on
>   dependent packages, like rebuild required packages after ABI bump.
>

Right, this would be a nice option. I could imagine this being implemented
as a configurable fedmsg listener that would launch rebuilds on certain
events
like bumps of certain packages, branching event, and possibly others.


>
>
> Thanks,
> Matthias
>
> [1] https://www.rdoproject.org/what/dlrn/
> --
> Matthias Runge <mru...@matthias-runge.de>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

COPR strategy

[Michal Novotny]

Hello,

we will have soon a planning meeting that should determine a more long-term
strategy and bring us to a team agreement on what COPR currently is and
what it should be in half a year or so.

I would like to kindly ask for some input here on the devel list to find
out what the actual expectations of COPR are and if there are any ideas
about what could COPR bring to the game.

clime
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: New copr-frontend release

[Michal Novotny]

On Mon, Aug 21, 2017 at 1:22 PM, Michal Novotny <cl...@redhat.com> wrote:

> Hello,
>
> On Mon, Aug 21, 2017 at 11:09 AM, Pavel Raiskup <prais...@redhat.com>
> wrote:
>
>> On Monday, August 21, 2017 10:42:00 AM CEST Michal Novotny wrote:
>> > Hello Kevin,
>> >
>> > sorry for the late response caused by me being on vacations.
>> >
>> > On Sat, Aug 12, 2017 at 2:35 AM, Kevin Kofler <kevin.kof...@chello.at>
>> > wrote:
>> >
>> > > Hi,
>> > >
>> > > Michal Novotny wrote:
>> > > > - "Follow Fedora branching" project switch that (if enabled) makes
>> COPR
>> > > > fork your rawhide chroots into the newly branched ones
>> > > > and hence user will have your packages available in their f27
>> systems
>> > > > and they will also be available for your upcoming builds
>> > > > (meaning you don't need to bootstrap anything from scratch). It
>> might
>> > > > take a few days after branching for this to actually take effect
>> because
>> > > > the new chroots need to be enabled in COPR first (and they should
>> also
>> > > > be in mock for that as well so that building in them works).
>> > > >
>> > > > You can enable the "Follow Fedora branching" option in project
>> settings
>> > > > and it will basically ensure that your rawhide builds will be copied
>> > > > into the new fedora-27-* ones when they become available in COPR.
>> > >
>> > > Why is that not the default?
>> >
>> > I thought there might people that would prefer rebuilding the packages
>> into
>> > the new chroot.
>>
>> It would look like use-case for new check-box;  aka rebuild all packages
>> during
>> fedora-branching time.
>>
>> > Perhaps there are none. In any case, some people only want to
>> > enable epel or Mageia chroots in their project. In their case, they
>> wouldn't
>> > have the rawhide chroot enabled so the option would do nothing anyway
>> but
>> > still, for them having the option 'on' does not make that much sense.
>>
>> +1 for having this enabled by default; IMO that's non-issue if that option
>> doesn't affect non-fedora buildroots.
>>
>> Also small issue report: from the description of the checkbox is unclear
>> whether
>> just new chroot is created in frontend database, or also build-results are
>> copyied from rawhide to branched on "backend" (binary packages).
>>
>
>
> It describes the way they are created: "automatically created for you (as
> soon as they are available) *as* *rawhide chroot forks*."
>
> Forking in COPR involves copying.
>


It's not very thorough description that's for sure.


>
>>
>> Pavel
>>
>> > clime
>> >
>>
>>
>>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: New copr-frontend release

[Michal Novotny]

Hello,

On Mon, Aug 21, 2017 at 11:09 AM, Pavel Raiskup <prais...@redhat.com> wrote:

> On Monday, August 21, 2017 10:42:00 AM CEST Michal Novotny wrote:
> > Hello Kevin,
> >
> > sorry for the late response caused by me being on vacations.
> >
> > On Sat, Aug 12, 2017 at 2:35 AM, Kevin Kofler <kevin.kof...@chello.at>
> > wrote:
> >
> > > Hi,
> > >
> > > Michal Novotny wrote:
> > > > - "Follow Fedora branching" project switch that (if enabled) makes
> COPR
> > > > fork your rawhide chroots into the newly branched ones
> > > > and hence user will have your packages available in their f27 systems
> > > > and they will also be available for your upcoming builds
> > > > (meaning you don't need to bootstrap anything from scratch). It might
> > > > take a few days after branching for this to actually take effect
> because
> > > > the new chroots need to be enabled in COPR first (and they should
> also
> > > > be in mock for that as well so that building in them works).
> > > >
> > > > You can enable the "Follow Fedora branching" option in project
> settings
> > > > and it will basically ensure that your rawhide builds will be copied
> > > > into the new fedora-27-* ones when they become available in COPR.
> > >
> > > Why is that not the default?
> >
> > I thought there might people that would prefer rebuilding the packages
> into
> > the new chroot.
>
> It would look like use-case for new check-box;  aka rebuild all packages
> during
> fedora-branching time.
>
> > Perhaps there are none. In any case, some people only want to
> > enable epel or Mageia chroots in their project. In their case, they
> wouldn't
> > have the rawhide chroot enabled so the option would do nothing anyway but
> > still, for them having the option 'on' does not make that much sense.
>
> +1 for having this enabled by default; IMO that's non-issue if that option
> doesn't affect non-fedora buildroots.
>
> Also small issue report: from the description of the checkbox is unclear
> whether
> just new chroot is created in frontend database, or also build-results are
> copyied from rawhide to branched on "backend" (binary packages).
>


It describes the way they are created: "automatically created for you (as
soon as they are available) *as* *rawhide chroot forks*."

Forking in COPR involves copying.


>
> Pavel
>
> > clime
> >
>
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: New copr-frontend release

[Michal Novotny]

Hello Kevin,

sorry for the late response caused by me being on vacations.

On Sat, Aug 12, 2017 at 2:35 AM, Kevin Kofler <kevin.kof...@chello.at>
wrote:

> Hi,
>
> Michal Novotny wrote:
> > - "Follow Fedora branching" project switch that (if enabled) makes COPR
> > fork your rawhide chroots into the newly branched ones
> > and hence user will have your packages available in their f27 systems
> > and they will also be available for your upcoming builds
> > (meaning you don't need to bootstrap anything from scratch). It might
> > take a few days after branching for this to actually take effect because
> > the new chroots need to be enabled in COPR first (and they should also
> > be in mock for that as well so that building in them works).
> >
> > You can enable the "Follow Fedora branching" option in project settings
> > and it will basically ensure that your rawhide builds will be copied
> > into the new fedora-27-* ones when they become available in COPR.
>
> Why is that not the default?
>
>
I thought there might people that would prefer rebuilding the packages into
the new chroot. Perhaps there are none. In any case, some people only want
to enable epel or Mageia chroots in their project. In their case, they
wouldn't
have the rawhide chroot enabled so the option would do nothing anyway but
still, for them having the option 'on' does not make that much sense.

clime
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

New copr-frontend release

[Michal Novotny]

Hello,

I am sending these release notes also to fedora-devel list (and not just
copr-devel list as usually) because they contain information
about upcoming Fedora branching and what features COPR provides to move the
set of packages from your rawhide chroots into the newly branched ones.

We have just released copr-frontend-1.118. Mainly this release prepares for
the upcoming branching by adding two features:

  - Batch package rebuilding ("Rebuild all" button in Packages view) so
that you can rebuild all your packages in the new chroots.
If you have build dependencies placed in you copr chroot as well, I
recommend linking the rawhide chroot first in "Repos"
setting ("Edit" button next to the chroot name in project settings) or
in "External repositories" field to be found in your project settings.
Otherwise you will probably need to click the "Rebuild all packages"
button a few times to get all the packages built successfully
(alas manual mockchain). We plan to introduce automatic build ordering
(based on BuildRequires) to optimize this feature in the foreseeing future.

  - "Follow Fedora branching" project switch that (if enabled) makes COPR
fork your rawhide chroots into the newly branched ones
 and hence user will have your packages available in their f27 systems
and they will also be available for your upcoming builds
 (meaning you don't need to bootstrap anything from scratch). It might
take a few days after branching for this to actually take effect because
 the new chroots need to be enabled in COPR first (and they should also
be in mock for that as well so that building in them works).

You can enable the "Follow Fedora branching" option in project settings and
it will basically ensure that your rawhide builds will be copied
into the new fedora-27-* ones when they become available in COPR.

Also, we have added syntax highlighting in code blocks in project
description and instructions and we switched the used library for markdown
rendering
(now python-CommonMark, before python-markdown).

Thank you for using COPR
COPR team

Full copr-frontend changelog:
- fork all succeeded buildchroots in RawhideToRelease
- follow Fedora branching project's option added
- allow to modify copr chroots
- syntax highlight in project description and instructions
- fix 500 on /api/coprs/build/ for auto-rebuilds
- Bug 1409894 - COPR invalidly renders markdown
- basic rebuild all packages feature added

* https://bodhi.fedoraproject.org/updates/FEDORA-2017-ab1891c41b
* https://bodhi.fedoraproject.org/updates/FEDORA-2017-4239263360
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

mock's dual bootstrapping enabled by default for existing copr projects

[Michal Novotny]

Hello,

while working on another thing, I noticed that when use_bootstrap_container
project option was introduced (Wed Jun 14 this year), it was introduced as
enabled for existing COPR projects at that time. That was not exactly
intended as this feature is experimental.

Enabling this option makes mock setup two chroots during build:

- "bootstrap" one with the latest dnf, rpm (and other build tools) for the
given build chroot (e.g. fedora-26-x86_64)
- the one where the build is actually run (which is of the same os,
version, and arch as the bootstrap one) and that is initially setup by the
tools from the bootstrap one

This makes build last a bit longer (in order of minutes depending on
package download speed) and it might cause a build to fail unexpectedly in
case there is e.g. bug in rawhide dnf (or in experimental dnf that is built
in your copr chroot).

If this option is disabled, host (builder) system dnf is used to setup the
build chroot. There is no bootstrap chroot setup and hence it is faster.

The longer running time might be a problem so, please, if you are a long
term users of COPR and you don't want the feature enabled, check your
project settings and disable it.

Sorry for accidentally enabling it
clime
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora, apps, and the Flatpak opportunity

[Michal Novotny]

I am no flatpack expert, but I think that really any container technology
in question should be just a porter of an rpm or set of rpms and there
should (could) be packaged ansible scripts that are able to setup and spawn
those containers e.g. in OpenShift or just on a host machine through ssh or
by other communication means. This approach is not bound to a particular
container technology and therefore provides huge amount of flexibility. We
could also actually provide flatpacks for downloading to create some 'halo'
effect but that again should be result of an automated image-creation
process in which we should be able to chose what kind of containerization
we want.

Really, if you can put rpms you want on the host system without any
container encapsulation, that will always be superior because containers
are just another added layer. They don't provide anything else than a way
to avoid conflicts. There is no gain in using them except portability but
that does not mean they need to be an end product. They can be an end
product but then that doesn't mean we need to stop working with rpm
internally. I am sorry if I am stating obvious things here.

clime

On Thu, Jul 20, 2017 at 5:54 AM, Kevin Kofler 
wrote:

> Matthew Miller wrote:
> > Containers (and particularly, Docker-style containers with Kubernetes
> > orchestration) are rapidly taking over the server world. This is not
> > hyperbole, and while one might fairly throw "everything old is new
> > again", it's not a fad. This is a real generational shift.
>
> This premise is already questionable. I can see large organizations like
> Red
> Hat using these (e.g., so they can easily move services from one physical
> server to another), but for the servers that I take care of (my personal
> VPS
> and my employer's server), I don't have any use for containers. All that
> they would give me is a lot more maintenance work. The typical server
> software is the same as always: Apache httpd, Tomcat, etc., which have all
> been packaged nicely as native packages for years. I am surely not the only
> admin who feels like that.
>
> Kevin Kofler
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: fedpkg new-sources broken?

[Michal Novotny]

Hello,

I was able to successfully use 'fedpkg new-sources' (still from f25) right
now.

clime

On Fri, Jul 14, 2017 at 11:04 AM, Fabio Valentini 
wrote:

> Right now, I can't build updates or new packages, because "fedpkg
> new-sources" is getting stuck (for more than 15 minutes) without error
> message (other than the bodhi deprecation warning) and it doesn't do
> anything until I kill it ...
>
> I can't pin down the exact date it stopped working (since I don't use it
> every day), but I first noticed it yesterday after installing updates from
> f26-updates-testing (although those updates probably didn't cause the bug,
> because downgrading to f26 stable packages didn't help).
>
> Am I the only one affected by this bug or has nobody else been building
> packages? ;)
>
> Fabio
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: 610 emails for a branch import in dist git?

[Michal Novotny]

Can you, please, show the emails or just one of them?

On Tue, Jun 27, 2017 at 11:34 PM, Michael Schwendt 
wrote:

> Whoever set up that service, seriously?
>
> Why would I receive 610 emails for activity in "epel7"? For packages with
> a longer git history, it will likely be thousands of emails.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Review swap

[Michal Novotny]

Hello,

I have implemented a set of macros specific for module development. I would
be happy to review your package if you can review mine:
https://bugzilla.redhat.com/show_bug.cgi?id=1461769

clime
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: Pull request/Changes to CentOS Extras repo??

[Michal Novotny]

Hello,

I would perhaps try to contact one of a package maintainers for
python-flask (see
https://admin.fedoraproject.org/pkgdb/package/rpms/python-flask/). Or, you
could file a request against
 Fedora EPEL on
Bugzilla to add Flask for python3. It's mainly about python3(4)-flask to
get into EPEL, all other packages are mostly its deps. That would be a
great achievement to get it there.

clime

On Thu, Apr 20, 2017 at 12:52 AM, Martin Juhl  wrote:

> Hi guys
>
> I have no idea where to go from here???
>
> Can anyone give me a hint???
>
> Regards
>
> Martin
>
>
> - Original meddelelse -
> Fra: "mj" 
> Til: "epel-devel" 
> Sendt: tirsdag, 4. april 2017 10:42:20
> Emne: [EPEL-devel] Re: Pull request/Changes to CentOS Extras repo??
>
> Ok... now I have a complete list:
>
> For building "python-flask-whooshee" in the copr project.. I need:
>
> python3-blinker:
> No other dependencies
>
> python3-flask:
> python3-itsdangerous
> python3-sqlalchemy
> python3-werkzeug - Depends on python3-sphinx
>
> python3-flask-sqlalchemy
> No other dependencies
>
> So all in all, it's 7 packages...
>
> I have the specs for building only the python3..
>
> What should I do to commit these for review???
>
> I'm already in the fedora packager group...
>
> Thanks...
>
>
> /Martin
>
> - Original meddelelse -
> Fra: "Orion Poplawski" 
> Til: "epel-devel" 
> Sendt: fredag, 31. marts 2017 16:39:37
> Emne: [EPEL-devel] Re: Pull request/Changes to CentOS Extras repo??
>
> On 03/30/2017 04:41 AM, Martin Juhl wrote:
> > Hi Again...
> >
> > So... I forgot that python34 comes from EPEL, so the CentOS guys can't
> enable python3 builds...
> >
> > So I guess these builds should be done in EPEL??
> >
> > I haven't got a list, but it's stuff like:
> >
> > python-blinker-1.3-2.el7.src.rpm
> > python-sqlalchemy-0.9.8-1.el7.src.rpm
>
> FYI - python3-sqlalchemy is already in EPEL7.
>
> python34-sqlalchemy.x86_64 1.1.3-1.el7 epel
>
>
>
> --
> Orion Poplawski
> Technical Manager 303-415-9701 x222
> NWRA/CoRA Division FAX: 303-415-9702
> 3380 Mitchell Lane or...@cora.nwra.com
> Boulder, CO 80301 http://www.cora.nwra.com
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
>
>
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

COPR rawhide repo links

[Michal Novotny]

Dear rawhide users,

if you have enabled a COPR repo in the last three months (since the
beginning of December last year till yesterday), then it points to
fedora-$releasever-$basearch. You can reenable it by using `dnf copr enable
` to get .repo file pointing to actual fedora-rawhide chroot in
the given project.

Sorry for this
clime
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: COPR and new chroot naming

[Michal Novotny]

On Tue, Feb 21, 2017 at 5:15 PM, Kevin Fenzi <ke...@scrye.com> wrote:

> On Tue, 21 Feb 2017 11:00:15 +0100
> Michal Novotny <cl...@redhat.com> wrote:
>
> > On Tue, Feb 21, 2017 at 10:28 AM, Vít Ondruch <vondr...@redhat.com>
> > wrote:
> >
> > > I honestly don't understand what is purpose of the f26 vs master.
> > > Why we have empty master currently (speaking of dist-git)? master
> > > should be the same as rawhide, as it is in Fedora.
> > >
> > Yes, I think that makes more sense as well.
> >
> >
> > P.S. Adding devel to the recipient list so that more people can
> > comment.
>
> Well, my thought was this would be a good way to clean out old stale
> projects. ie:
>
> right now we have f26 (rawhide), f25, f24
>
> once we branch f26, projects have f26, f25, f24 and if they like they
> can enable and rebuild for the now existing f27 (rawhide).
>
> When f24 goes eol and is disabled, look at projects that don't have any
> builds anymore and remove them.
>
> repeat each cycle. This means you need to pay attention and rebuild
> your coprs for new branches as they appear, but it also means if you
> don't the old project disappears.
>

That's true but maybe if we make sure the time of the latest build is
communicated
clearly to the user of the copr, it will be enough.


>
> Of course many projects also build for epel, so they would stick around
> for that reason for a long time.
>
> If we move back to having a rawhide/devel/master repo the problem
> becomes "which rawhide" ? if you build something in that branch a year
> ago, what are the chances it will still work?
>
>
Yeah, not very high chances. However, rawhide is still moving so people
probably
do expect the packages there not to have very wide 'it-works' lifespan.

If I consider a use-case of a package developer/maintainer that wants to
prepare
his or her package for next Fedora release, then I think that for those
COPR users
(I met one), rawhide naming is more intuitive and I would like to be good
to them.


> Just my thoughts...
>
>
Thank you, Kevin.


> kevin
>
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: COPR and new chroot naming

[Michal Novotny]

On Tue, Feb 21, 2017 at 10:28 AM, Vít Ondruch <vondr...@redhat.com> wrote:

> I honestly don't understand what is purpose of the f26 vs master. Why we
> have empty master currently (speaking of dist-git)? master should be the
> same as rawhide, as it is in Fedora.
>
Yes, I think that makes more sense as well.


P.S. Adding devel to the recipient list so that more people can comment.

> Vít
>
> Dne 21.2.2017 v 10:05 Michal Novotny napsal(a):
>
> Hello folks,
>
> We have quite recently changed naming of rawhide chroot to fXY in COPR and
> I would like to know your opinion about it.
>
> As branching is behind the door, I tried to consider it again and slightly
> changed my mind. The main problem with just fXY is that it is probably not
> very intuitive. "rawhide" tells clearly that rawhide repos are used whereas
> with just fXY, the repos used for the chroot need to be switched at
> branching (from rawhide to the fXY ones).
>
> We were probably trying to be too fancy here thinking that the follow-up
> features (all package rebuilding and chroot forking) will complement it
> well. These features can, however, work with both namings and the "rawhide"
> chroot just plays much better with mock and how it introduces the new
> chroot configs.
>
> We can go either way but to me the "just-call-it-rawhide" seems to be more
> simple now while also providing nicer user experience.
>
> clime
>
>
>
>
>
>
>
>
> ___
> infrastructure mailing list -- infrastruct...@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
>
>
>
> ___
> infrastructure mailing list -- infrastruct...@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-leave@lists.
> fedoraproject.org
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Copr f26 with pkgconfig

[Michal Novotny]

On Fri, Feb 3, 2017 at 12:07 PM, Didier Fabert 
wrote:

> Hi there,
>
> I'm unable to build netdata package for f26 on copr. The error, in file
> root.log.gz, was about pkgconfig:
> > Error: package pkgconf-pkg-config-1.2.1-1.fc26.x86_64 conflicts with
> pkgconfig < 1:0.29.1-2 provided by pkgconfig-1:0.29.1-1.fc25.x86_64
>
> Yes, pkgconfig is explicitly mark as BuildRequires.
>
> Does anybody have an idea to solve this problem ?
>
> Full logs are https://copr-be.cloud.fedoraproject.org/results/
> tartare/netdata/
> fedora-26-x86_64/00506909-netdata/
> 
>
>
This problem is related to: *Bug 1096506*
 and was fixed in
dnf-1.1.10-3.
On
copr builders, there is currently dnf-1.1.9-2. I already submitted a patch
to
ensure dnf is latest on builders but it will take a while to take effect. I
will contact you as soon as the problem is resolved so that you can retry
your build.

clime

P.S.: I also made this bug
https://bugzilla.redhat.com/show_bug.cgi?id=1419185
that you can follow


> Sincerely,
>
> Didier.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: COPR auto-rebuilds on pagure commits

[Michal Novotny]

On Mon, Nov 7, 2016 at 6:57 PM, Matthew Miller <mat...@fedoraproject.org>
wrote:

> On Mon, Nov 07, 2016 at 03:13:43PM +0100, Michal Novotny wrote:
> > I'd like to announce that we now support package auto-rebuilding on a new
> > commit(s) into a Pagure repository.  Apart from having your package repo
> > hosted in Pagure, you just need to enable firing of fedmsg notifications
> > for new commits by clicking a single checkbox in 'Hooks' section...well,
> > then you also need to save this setting and have auto-rebuilding enabled
> > for the copr package but that really is it, I promise :).
>
> That's really cool. Where is this documented?
>
>
Well, at the moment, it is documented here:
https://fedorahosted.org/copr/wiki/UserDocs#PagureWebhooks
But as fedorahosted.org is being sunset, we will need to move the docs
somewhere. Pagure seems
like a nice option, especially after I have seen its code.


>
> --
> Matthew Miller
> <mat...@fedoraproject.org>
> Fedora Project Leader
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

COPR auto-rebuilds on pagure commits

[Michal Novotny]

Hey,

I'd like to announce that we now support package auto-rebuilding on a new
commit(s) into a Pagure repository.  Apart from having your package repo
hosted in Pagure, you just need to enable firing of fedmsg notifications
for new commits by clicking a single checkbox in 'Hooks' section...well,
then you also need to save this setting and have auto-rebuilding enabled
for the copr package but that really is it, I promise :).

clime
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org