rhel 8 beta mock configs and EOLed mock configs

[Miroslav Suchy]

Hi,
I just released [1] new mock-core-config package which include new
rhelbeta-8-* configs.
This will allows you to build packages on top of RHEL 8 Beta. This is
temporary config. I put them there so you can experiment with your
builds and prepare for EPEL 8 once it will be available.
This config will be removed when Beta ends.

Additionally I moved these configs:
epel-5-i386.cfg
epel-5-x86_64.cfg
fedora-25-aarch64.cfg
fedora-25-armhfp.cfg
fedora-25-i386.cfg
fedora-25-ppc64.cfg
fedora-25-ppc64le.cfg
fedora-25-s390x.cfg
fedora-25-x86_64.cfg
fedora-26-aarch64.cfg
fedora-26-armhfp.cfg
fedora-26-i386.cfg
fedora-26-ppc64.cfg
fedora-26-ppc64le.cfg
fedora-26-s390x.cfg
fedora-26-x86_64.cfg

to /etc/mock/eol to clearly mark them as EOLed distribution. They are
there for archive purpose, I will not maintain them, but they should
generaly work. You can use them as:

  mock -r eol/fedora-26-x86_64  foo.src.rpm

[1] https://bodhi.fedoraproject.org/updates/FEDORA-2018-86a0a48569

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

[EPEL-devel] rhel 8 beta mock configs and EOLed mock configs

[Miroslav Suchy]

Hi,
I just released [1] new mock-core-config package which include new
rhelbeta-8-* configs.
This will allows you to build packages on top of RHEL 8 Beta. This is
temporary config. I put them there so you can experiment with your
builds and prepare for EPEL 8 once it will be available.
This config will be removed when Beta ends.

Additionally I moved these configs:
epel-5-i386.cfg
epel-5-x86_64.cfg
fedora-25-aarch64.cfg
fedora-25-armhfp.cfg
fedora-25-i386.cfg
fedora-25-ppc64.cfg
fedora-25-ppc64le.cfg
fedora-25-s390x.cfg
fedora-25-x86_64.cfg
fedora-26-aarch64.cfg
fedora-26-armhfp.cfg
fedora-26-i386.cfg
fedora-26-ppc64.cfg
fedora-26-ppc64le.cfg
fedora-26-s390x.cfg
fedora-26-x86_64.cfg

to /etc/mock/eol to clearly mark them as EOLed distribution. They are
there for archive purpose, I will not maintain them, but they should
generaly work. You can use them as:

  mock -r eol/fedora-26-x86_64  foo.src.rpm

[1] https://bodhi.fedoraproject.org/updates/FEDORA-2018-86a0a48569

Miroslav
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org

`best=1` in new Mock

[Miroslav Suchy]

Hi,
I just released new version of Mock. And I want to quote one important
change from the release notes so everyone is aware of it:

https://github.com/rpm-software-management/mock/wiki/Release-Notes-1.3.3

All chroot (but rawhide) configs now contains best=1.
This way DNF will always try to install latest package. If its
dependence cannot be satisfied DNF will report an error. Without this
DNF may silently install some older version which does not have broken deps.
This is fine for regular user, but not for buildsystems, where
maintainers usually want to use latest version.

Note that this change may result in sudden build failure, which
previously silently succedded. In this case, please check your
BuildRequires and ask maintainers of those build deps to resolve broken
dependency. This option was not added to rawhide chroots as there are
broken dependencied very often.

Additionaly option best=1 is used for repos passed to mockchain using -a
option.


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

15 thousands python3-* packages for Fedora

[Miroslav Suchy]

Hi,
I just finished packaging of 15 634 python3-* packages for Fedora.
  https://copr.fedorainfracloud.org/coprs/g/copr/PyPI3/
  You can click on Builds and Monitoring tab. But be aware that those
pages are HUGE (40MB) and they are loading and rendering several
minutes. Tab "Packages" is timeouting and this will be fixed in next
release.

I am now building python2-* packages too:
  https://copr.fedorainfracloud.org/coprs/g/copr/PyPI2/

This is only for rawhide and for statistic purposes, but there will be
more. Read on.

Once the build of python2-* packages will finish, I gather the data and
build those packages once again in other project. Packages which
succeeded in both PyPI2 and PyPI3 projects will be build with both
python2-* and python3-* subpackages. Everything else will be build with
only one subpackage.

Why I am doing this?
Because I can. :) While I can imagine several obvious scenarios how this
can help Fedora users, I anticipate there are some use cases which I can
not imagine now, and which will surprise me for sure.

Why I'm writing this?
This projects is not yet finished. But this is first result, which can
be used/tested/remixed. Once this rebuilds for all Fedoras and Epels
will be finished I will announce it to Fedora users. But right now I'm
focused on you - developers.
These packages were automatically generated by pyp2rpm. They may work
(or not). So you can create some (automated) tests which can test
functionality of all those packages. You can look why your favorite
module failed (there is still 50k packages which are failing to build
now) and suggest improvements to pyp2rpm:
  https://github.com/fedora-python/pyp2rpm
Or come with something else which can raise the quality of those
packages. The future is open and waiting for your ideas.

If you have any question or idea (anything missing in our API of CLI
tools?), do not hesitate to contact me.

Mirek
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Copr ppc builds are stopped temporary

[Miroslav Suchy]

We have temporary problems with ppc builders so I stopped ppc builds for
now.
This does not affect i386 and x86_64 queue.
I anticipate that tomorrow I may start it again.

Mirek Suchy
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Copr cannot download SRPM - no space on device

[Miroslav Suchy]

Dne 19.4.2016 v 13:57 Robert Mayr napsal(a):
> Err...ok, I saw there is a limit of 1GB, so I cleaned up the repo a bit
> and it's running now.
> Sorry for the noise.

Nope, there was really full storage. I cleaned it up, so that is reason
why subsequent build passed.

Mirek
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

SLA of Copr and changes in future

[Miroslav Suchy]

We are discussing in Fedora Infrastructure about level of SLA of some
services. And mainly because of Copr. There are some other services e.g.
Jenkins, Taiga. However Copr is probably most popular. Copr service was
from begging meant as somehow beta version and did not pass all the
requirements Fedora Infrastructure team has for Fedora services.

So rather later than never - I would like to emphasize:

 Copr is experimental service provided as a courtesy for the
 community.  There is no expectation of a SLA and the service may be
 changed from time to time as part of its further development.

This is the reason why Copr changed hostname recently. From
copr.fedoraproject.org to copr.fedorainfracloud.org.
There is ongoing discussion on Fedora Infrastructure mailing list, that
only fully supported services should remain in fedoraproject.org domain.
All experimental services should be moved to fedorainfracloud.org.
Recently there was suggestion to use http://fedoracommunity.org/. So it
is not settled down and the resolution may change in near future.

Copr team works hard to become fully supported service in future and
re-appear again as copr.fedoraproject.org. This will not be painless.
Beside a lot of work for my team, it will mean rebuilding of all
packages. We will provide tool which will easy the migration for you.
However I have no precise ETA when we met all Fedora Infrastructure
requirements.

In the mean time, it was announced on copr-devel list that the redirect
from copr.fedoraproject.org will be discontinued on Tuesday 22nd March.

Miroslav Suchý
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

copr-fe.cloud.fedoraproject.org is no more

[Miroslav Suchy]

Several of you reported expired certificate of
  copr-fe.cloud.fedoraproject.org

This url was only used at very earlier stage of this project and now is
deprecated. It still exist albeit with expired certificate, but it will
be removed soon.
Please replace your bookmarks with either
  copr.fedoraproject.org
or
  copr.fedorainfracloud.org

The second one is preferred for now.

Miroslav Suchy
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Planned Outage: Copr upgrade - 2016-02-11 08:00 UTC

[Miroslav Suchy]

There will be an outage starting at 2016-02-11 08:00 UTC, which will
last approximately 1 hour.

To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run:

date -d '2016-02-11 08:00 UTC'

Reason for outage: We need to reprovision Copr servers.

Affected Services: copr.fedoraproject.org
copr-be.cloud.fedoraproject.org copr-keygen.cloud.fedoraproject.org
copr-dist-git.cloud.fedoraproject.org

Services not listed are not affected by this outage.

Contact Information: ​​​msu...@redhat.com

Ticket Link:
https://fedorahosted.org/fedora-infrastructure/ticket/5097

Please join #fedora-admin or #fedora-noc on irc.freenode.net or add
comments to the ticket for this outage above.
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel-announce@lists.fedoraproject.org

Planned Outage: Copr upgrade - 2016-02-11 08:00 UTC

[Miroslav Suchy]

There will be an outage starting at 2016-02-11 08:00 UTC, which will
last approximately 1 hour.

To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run:

date -d '2016-02-11 08:00 UTC'

Reason for outage: We need to reprovision Copr servers.

Affected Services: copr.fedoraproject.org
copr-be.cloud.fedoraproject.org copr-keygen.cloud.fedoraproject.org
copr-dist-git.cloud.fedoraproject.org

Services not listed are not affected by this outage.

Contact Information: ​​​msu...@redhat.com

Ticket Link:
https://fedorahosted.org/fedora-infrastructure/ticket/5097

Please join #fedora-admin or #fedora-noc on irc.freenode.net or add
comments to the ticket for this outage above.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Copr GPG keys

[Miroslav Suchy]

Hi,
I just released new version of distribution-gpg-keys package:
  https://bodhi.fedoraproject.org/updates/FEDORA-2016-1a7ed2ffe8
It now includes GPG keys of all Copr projects. Thanks to clime for
writing the script which retrieve all those keys.

I plan to upgrade those data regularly. Although I'm still not sure what
will be the definition of 'regularly' yet. Probably every month.

Mirek
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: COPR: Fedora 21 is still available as chroot

[Miroslav Suchy]

Dne 23.1.2016 v 13:03 Igor Gnatenko napsal(a):
> Looks like a bug in COPR. Miro?
> 
> On Sat, Jan 23, 2016, 12:33 PM Heiko Adams  > wrote:
> 
> FYI: Fedora 21 is still available as chroot on COPR.

https://lists.fedorahosted.org/archives/list/copr-devel%40lists.fedorahosted.org/thread/AB6YLHJJYGEQZN4LKBH5MVHPEJG2BE2S/

Copr does not follow the same schedule as Koji. And I usually keep the
chroot enable little bit longer.

Mirek
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: COPR repo in mock?

[Miroslav Suchy]

Dne 19.1.2016 v 06:51 Dmitrij S. Kryzhevich napsal(a):
> Like any others. Provide information about repo to /etc/mock/YOURCONFIG.cfg
> In most cases in would be: /etc/mock/default.cfg
> 
> You could find details for your particular copr repo in file with
> corresponding name in /etc/yum.repos.d dir if this repo already
> worldwide enabled in your system

No need to put anything to /etc/mock. You can put it in your working
directory and not mess your /etc directory.

So:
cp /etc/mock/fedora-23-x86_64.cfg ./myconfig.cfg
vim ./myconfig.cfg

at the end of
config_opts['yum.conf'] = """
[main]
...
[updates-testing-debuginfo]
...
enabled=0
"""

put the content of copr repo file (before the """) e.g.

...
enabled=0
[msuchy-spark-cli]
name=Copr repo for spark-cli owned by msuchy
baseurl=https://copr-be.cloud.fedoraproject.org/results/msuchy/spark-cli/fedora-$releasever-$basearch/
skip_if_unavailable=True
gpgcheck=1
gpgkey=https://copr-be.cloud.fedoraproject.org/results/msuchy/spark-cli/pubkey.gpg
enabled=1
"""

and then just call:
mock -r ./myconfig.cfg your.src.rpm

Mirek
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Planned Outage: Copr upgrade - 2016-01-19 20:00 UTC

[Miroslav Suchy]

Dne 18.1.2016 v 15:28 Miroslav Suchý napsal(a):
> 
> Planned Outage: Copr upgrade - 2016-01-19 20:00 UTC
> 
> There will be an outage starting at 2016-01-19 20:00 UTC, which will last 
> approximately 1 hours.
> 
> During the outage backend will stop processing new task and they will be 
> queued in frontend and processed just after the
> outage.

The outage is over.
It took longer then expected due some problems. I will post tomorrow
post-mortem on copr-devel mailing list with more details for those who
are interrested in.

During the upgrade several builds failed due problem with signing
process. Please resubmit those builds.
I apologize for the inconvenience.

Mirek Suchy


--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

COPR infrastructure issues caused build failures

[Miroslav Suchy]

Hi,

Throughout the day of November 24th, 2015 there have been multiple build
failures in COPR because of problems with the COPR infrastructure.
If your build failed with only a mockchain.log.gz file which contains
the following line:
"Failed to obtain srpm from dist-git", or something alike that, that was
caused by this
infrastructure issue.

We have just found and fixed the root cause of this problem, so any
builds from now on should be successful.
If you have any builds that failed and only produces a mockchain.log.gz,
please resubmit your build and it should go through correctly.

If you have any build failures where you are unsure whether they're
caused by this issue,
or have any other questions, feel free to email me or come by on IRC
(#fedora-buildsys).

Mirek Suchy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

New package distribution-gpg-keys

[Miroslav Suchy]

Hi,
I created new project distribution-gpg-keys:
  https://github.com/xsuchy/distribution-gpg-keys

There are various GPG keys used to sign RPM packages. Right now:
  * centos
  * epel
  * fedora
  * redhat
  * rpmfusion

In future I will try to add all Copr gpg keys.

If you find it useful too, you can do package review:
  https://bugzilla.redhat.com/show_bug.cgi?id=1272235

Mirek Suchy

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora Ring 0 definition

[Miroslav Suchy]

Dne 14.9.2015 v 23:10 Brendan Conoboy napsal(a):
>> /Then/ we could start thinking about /truly minimal/ concepts,
>> perhaps  “container minimal” = “the minimal set needed to start and
>> run an executable dependent on Fedora ABI” (e.g. kernel version
>> requirement +glibc+locale data+Python 3 interpreter+…, useful for
>> building containers), “VM minimal” could be “the minimal contents of a
>> VM needed to start and run…” (e.g. kernel
>> implementation+init+container minimal, useful for single-app VM), “CLI
>> minimal”, …
>>  Mirek
> 
> Right, so I don't think minimal is the end goal, I think the OS (not the
> distribution) is the end goal- minimal is presumably a subset of the OS.

And how we call this "truly minimal concept"? Ring -1?

I would like to have those Rings zero based, where zero is absolute
minimum to run. Somewhere. Not necessary on bare metal.
The whole "OS" can be Ring 1. There is still plenty of numbers remaining.

Mirek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

New version of Copr (includes dist-git)

[Miroslav Suchy]

It is my pleasure to announce that we just upgraded
  https://copr.fedoraproject.org

It includes several major improvements:

* UI converted to PatternFly [1]. Most visible change is that tables
(e.g. list of builds) can be sorted using any column and you can filter
visible rows using any value.

* dist-git support -- We store your SRPM in dist-git now. It is not
accessible directly using fedpkg (it is in plan later). Dist-git is
browsable via cgit [2]. This allows us to offer you upload of SRPM
directly from your workstation. Just navigate to:
  New Build - Upload SRPM
or if you upgrade to python-copr-1.58-1 (submitted to updates just
today) then you can do:
  copr-cli build name/project ./some.src.rpm
While we assume that uploading SRPM will be most popular method, we
preserved option to pass SRPM url.
You can see new state of your build - Importing. It is obviously the
moment when we import your SRPM into dist-git.

* In project properties (Edit tab) you can now add you email if you want
to be contacted by users in case of some problems with your project.

* We improved queue handling of various architectures. This should fix
those long waiting time of PPC64LE builds.

Big kudos go to Valentin G., Adam Š. and Jakub K., who implemented those
features.

[1] https://www.patternfly.org/
[2] http://copr-dist-git.fedorainfracloud.org/cgit/

Mirek Suchý

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

New architecture in Copr: PPC64LE

[Miroslav Suchy]

Hi,
I just enabled new architecture in Copr - PowerPC 64 LE (little endian).

There are those chroots available:
 * fedora-21-ppc64le
 * fedora-22-ppc64le
 * fedora-rawhide-ppc64le

This happened as co-operation of Red Hat, Brno University of Technology
and IBM.

I would like to thanks D, Horak and J. Capik from Secondary
Architectures for cooperation and making this happen.

To enable this architecture on existing project, you need to navigate to
your project - click on Edit tab - choose PPC64LE chroots - Save and
then resubmit your SRPMs.

Enjoy and happy hacking

Mirek Suchy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Failing rawhide builds in Copr

[Miroslav Suchy]

I have been approached by some of you, who already found out that 
rawhide builds in Copr are failing with:


DEBUG util.py:388:  rpmlib(ScriptletExpansion) = 4.9.0-1 is needed by 
glibc-common-2.21.90-5.fc23.x86_64


This is caused by
  https://bugzilla.redhat.com/show_bug.cgi?id=156477

Unless this is resolved, there is nothing I can do about it.

Sincerly

Mirek
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Mock, Rawhide and DNF

[Miroslav Suchy]

Hi,
I just released mock-1.2.7. It have - beside one small bug and new F22 
configs - one important change.


The rawhide configs have this one line included:
  config_opts['package_manager'] = 'dnf'
which means that Mock will use DNF for building packages for rawhide 
targets. There are two consequences, which I would like to point out.


This change is done only in Mock, but not in Koji. M.McLean is working 
on Koji code enhancement, which allow to do this change in Koji too. The 
ETA is 1-3 months. During this transient period Koji will use YUM for 
rawhide targets, while your local mock builds will use DNF. We would 
like to use this period to get broader testing of Mock+DNF before it 
reach Koji. If you experience some problem (I believe there will be 
none) please report it, so we can address it before we deploy this 
change on Koji.


RHEL/EPEL users do not have DNF available, therefore they are unable to 
build packages for Fedora Rawhide. There is however a workaround. Just 
change this line:

  config_opts['package_manager'] = 'dnf'
to this:
  config_opts['package_manager'] = 'yum'
or you can simply delete it because Yum is the default.
Or you can pass --yum to mock.
However you should be aware that you are using different depsolving and 
you may get slightly different result.


And last one notice: I built mock-1.2.7 only for rawhide, F22 and F21 
for now.
I will create updates for F20, Epel7 and EL6 on Wednesday next week as I 
do not want to interrupt quarantine period of previous update in bodhi, 
which carry some important fixes.


Mirek
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Copr outage

[Miroslav Suchy]

Hi,
we experienced outage of Copr backend from 2015-02-09 20:00 to 
2015-02-10 01:00 UTC.


I had to re-install backend. All data are preserved and Copr is up and 
running now.


However during this period some builds were processed before all chain 
was ready. Therefore some packages build in this time frame have been 
marked as failed just because signing did not work at that time.


I am sorry if it cause some harm or confusion.

Mirek Suchy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Broken deps in rawhide (coreutils)

[Miroslav Suchy]

Today I got report that there are failed builds in Copr for rawhide 
chroots. [1]


After investigation I find that coreutils are installed too late, so 
they are not available to previous postcripts:



  Installing : crypto-policies-20140905-1.git4649b7d.fc22.noarch 
  136/239

/usr/bin/update-crypto-policies: line 39: cat: command not found
/usr/bin/update-crypto-policies: line 43: cat: command not found
Couldn't read current profile
warning: %post(crypto-policies-20140905-1.git4649b7d.fc22.noarch) 
scriptlet failed, exit status 1
Non-fatal POSTIN scriptlet failure in rpm package 
crypto-policies-20140905-1.git4649b7d.fc22.noarch

...
  Installing : libblkid-2.25.1-1.fc22.x86_64 
  138/239

/var/tmp/rpm-tmp.yCcv5b: line 4: mkdir: command not found
...
  Installing : pam-1.1.8-18.fc22.x86_64 
  143/239

/var/tmp/rpm-tmp.4J2sJD: line 3: /usr/bin/install: No such file or directory
warning: %post(pam-1.1.8-18.fc22.x86_64) scriptlet failed, exit status 127
Non-fatal POSTIN scriptlet failure in rpm package pam-1.1.8-18.fc22.x86_64
  Installing : coreutils-8.23-4.fc22.x86_64 
  144/239


This is just small sample, there is much more errors.
And it is not just coreutils (but that produce most errors). E.g. I seen 
errors caused by ordering of libXft too:


  Installing : pango-1.36.8-1.fc22.x86_64 
  133/239
/usr/bin/pango-querymodules-64: error while loading shared libraries: 
libXft.so.2: cannot open shared object file: No such file or directory
  Installing : libXft-2.3.2-2.fc22.x86_64 
  134/239


And there may be even more examples. You can try it yourself by:
rm -rf /var/lib/mock/fedora-rawhide-x86_64/root/*
/usr/bin/yum --installroot /var/lib/mock/fedora-rawhide-x86_64/root/ 
--releasever rawhide install @buildsys-build --setopt=tsflags=nocontexts 
--nogpgcheck


Few days ago it seemed to work. Does somebody have idea what changed 
recently? Is is because of some change in rpm, yum, something else?

Why it work in koji [2]?
Why is pam installed before coreutils even when pam have
Requires(post): coreutils, /sbin/ldconfig
?

Mirek


[1] 
http://copr-be.cloud.fedoraproject.org/results/jwboyer/kernel-playground/fedora-rawhide-x86_64/kernel-3.18.0-0.rc1.git0.1.playground.fc22/root.log
[2] 
https://kojipkgs.fedoraproject.org//packages/kernel/3.18.0/0.rc1.git0.1.fc22/data/logs/i686/root.log

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: top in Rawhide

[Miroslav Suchy]

On 10/21/2014 03:33 PM, Richard W.M. Jones wrote:

Anyone worked out how to get top to give a normal (ie. old) display in
Rawhide?


It is in F21 too.

Type:
  tttmmVbz1W
and you get original look and feel.

For discussion see bug 1153049.

Mirek
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: civil discussion on fedora lists

[Miroslav Suchy]

On 10/17/2014 08:31 PM, Matthew Miller wrote:

You can say something like I'm not sure I understand the point you are
making. Particularly, I don't see how __ follows. Can you explain
that in more depth?

And conversely, if you feel like your position isn't being listened to, try
I guess I'm not making myself very clear. Let me try to restate Does
this make more sense?


Ha Ha. I heard exactly that from my English teacher several weeks ago. 
For myself, this is cultural difference too. I would never use such 
wording in my native language. (Disclaimer: I'm not targeting the 
original thread, but disagreement in general).



You don't need to agree in the end, but you can get a better understanding,
and unlike a back-and-forth email jousting match, it can be helpful for
people reading along as well.


If you guys are replying to the same thread twice+ in hour  then there 
is something wrong. Please leave the second email open and send it 
tomorrow. In the mean time:

 * others can step into discussion too
 * you may find there was just cultural difference
 * you may find there was language barrier as lots of contributors does 
not speak English fluently.
 * or it is just not worth to continue in discussion and rather do some 
coding.
If you still find your email useful the day after, then send it. But I 
very often delete it, because when the dust settle I do not find it 
constructive any more.


Mirek

P.S. Yes, this email have been in Draft folder over night before I hit 
Send button.


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Wallpapers in portrait orientation

[Miroslav Suchy]

Hi,
I'm thinking can we ship for Fedora 22 some wallpapers in portrait
orientation?

We always shipped wallpapers in landscape mode. But I - and quite people
around me - have monitors rotated by 90°, which I personally find much
better for development.
Right now I have cropped wallpapers, and it would be nice to have some
wallpapers in default configuration in portrait orientation. In fact,
just one would be good start.

Comments?

Mirek Suchy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

New Copr release

[Miroslav Suchy]

Hi,
I just deployed new version of Copr.
  https://copr.fedoraproject.org/

Changes:
* a lot of small bugfixes
* each src.rpm have separate task now - you can still submit bunch of
src.rpm, but the list of src.rpm are split and each src.rpm is submitted
to builders as one task. This means that Monitor and deleting is more
predictable.
* you can submit src.rpm only to subset of chroots you selected for your
project.
* when someone request permission on your project, then copr sends you
notification via email now.
* repo files now have better URL (which ends with .repo suffix), which
should make yours wget happy.
* new API calls:
  * call for fulltext searching (this is first step to dnf copr search)
  * you add additional repos to project via API call now
  * when submitting src.rpm, then you get list of ids instead of one id.

The last change will probably break old 'copr-cli'. When you submit
src.rpm it will be sucesfully sent, but then copr-cli query the status
of build and in this phase old clients will throw error.
It is not fatal, your packages will be build, but you will have to check
the status on WebUI. Or upgrade to newer 'copr-cli' which I just sent to
updates-testing.

I wish you happy building.

-- 
Miroslav Suchy, RHCE, RHCDS
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

New version of Copr

[Miroslav Suchy]

Hi,
I just deployed new version of Copr.

Changes:
 * copr-cli has been build for epel6 (no planned build for el5 due
dependency on python-requests)
 * you should see less internal server errors. Especially when deleting
tasks with multiple srpm
 * All packages produced by Copr now have as vendor Fedora Project COPR
(username/project)
 * if you add new chroot to your project, you can easily resubmit
missing builds from Monitor tab.
 * if you are logged in, then time in output respect your timezone which
you have in FAS.
 * previously sometime yum repo was not updated after successful build -
this has been fixed

Enjoy:
http://copr.fedoraproject.org/

Mirek Suchy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora 18 End of Life

[Miroslav Suchy]

On 01/14/2014 10:31 PM, Dennis Gilmore wrote:

As of 14th January 2014, Fedora 18 has reached its end of life for
updates and support. No further updates, including security updates,
will be available for Fedora 18. A previous reminder was sent on
December 18th [0].


How does this affect Copr?

I will keep Fedora 18 for additional 3 months there. Then it will be 
removed.


I'm still unsure what it will mean for existing Fedora 18 repository. I 
you want to discuss it, you are welcome to copr-devel@ mailing list.


Mirek

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora 18 End of Life

[Miroslav Suchy]

On 01/16/2014 09:05 AM, Miroslav Suchy wrote:

I'm still unsure what it will mean for existing Fedora 18 repository. I
you want to discuss it, you are welcome to copr-devel@ mailing list.


So in 3 months I had to come with some solution what to do with old 
repositories. Options which comes to my mind - thinking loudly:


1) Give people warning and suggest them to archive it somewhere 
(repos.f.o, their own web...). And then remove F18 repos from Copr.


2) I can not remove the chroot from DB as that would remove access to 
repo files and is basically equal to option 1)


3) Chroots have flag if they are active. And overview page shows repo 
file only for those which are active. So I can just flip this attribute. 
Which will mean users can not select this chroot for building. No one 
will be allowed to build into that chroot. And in overview I can add new 
section Archived repo with some big red warning, that it is just for 
archived and not maintained in any meaning of that word.


While the last option is probably best, I'm not sure if this is worth 
the effort. How many people will appreciate having archived old repos?


Mirek
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

New release of Copr

[Miroslav Suchy]

Hi,
I just deployed new version of Copr to
  https://copr.fedoraproject.org/

I deployed it mostly to get rig of few tracebacks we get regularly.
But there is some enhancements as well:

* https is available. Self signed certificate right now. Final 
certificate is on the way.


* no need to enter your fas name when log in.

* you can delete individual builds.

* if you did not enter description/instructions Copr display little bit 
dangerous description.


* and you should get less Internal Server Error when using Copr.

I will release new copr-cli in few days, but only enhancement will be 
availability on epel5 and epel6.


Mirek
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

New version of Copr

[Miroslav Suchy]

I just deployed new version of Copr at:
  http://copr.fedoraproject.org

It have only one feature: you can now build in epel-7-x86_64!

To be precise - the name epel is little bit misleading, because it is 
right now based on RHEL 7 Beta and does not include EPEL repo, because 
it does not exists yet.
But one day I will flip to Centos 7 and EPEL 7 and I do not want you to 
change chroots and configs, while I want to provide you the option of 
hacking your packages on top not-yet-finished RHEL 7.


Mirek

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Why authconfig create -ac files

[Miroslav Suchy]

I just wonder why `authconfig` creates:
  /etc/pam.d/system-auth - system-auth-ac
  /etc/pam.d/postlogin - postlogin-ac
  /etc/pam.d/password-auth - password-auth-ac
  etc.

Why those links and why -ac suffix? Why it does not modify original 
files directly?

Is there some story behind?

Mirek
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: dnf-0.4.11

[Miroslav Suchy]

On 01/12/2014 08:27 PM, Reindl Harald wrote:

dnf clean all without dnf --enablerepo=updates-testing clean all does
exactly*nothing*  in case of updates-testing, the same for YUM simply
because folders of non-enabled repos are not relevant for any operation


And is this correct behavior? (and yum behaves same way, so same 
question apply to yum as well).


Man page for yum state:

yum clean metadata
Eliminate  all  of the files which yum uses to determine the remote 
availability of packages. Using this option will force yum to

download all the metadata the next time it is run.

There is no statement that it apply only for *currently enabled* repository.
I would expect that it clean *all* metadata.

I was recently very surprised that when I done :

# rpm -q yum
yum-3.4.3-128.fc20.noarch
# yum clean all
...
# du -sh /var/cache/yum/x86_64/*
225M/var/cache/yum/x86_64/19
111M/var/cache/yum/x86_64/20
406M/var/cache/yum/x86_64/rawhide

that there is a lot of data in /var. To be precise - after this 
operation I would expect that /var/cache/yum/x86_64/ would have zero 
size. And not 730 MB.


DNF is on the same boat:
# rpm -q dnf
dnf-0.4.9-1.fc20.noarch
# dnf clean all
Cleaning repos: fedora rpmfusion-free-updates adobe-linux-x86_64 Dropbox 
rpmfusion-nonfree-updates rpmfusion-free updates rpmfusion-nonfree

Cleaning up Everything
# du -sh /var/cache/dnf/x86_64/*
114M/var/cache/dnf/x86_64/19
34M /var/cache/dnf/x86_64/20

Do others feel that this is correct or incorrect behavior?

Mirek


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: dnf-0.4.11

[Miroslav Suchy]

On 01/12/2014 11:23 PM, Alec Leamas wrote:

Well, IMHO the docs are actually quite clear on that 'all' refers to all
metadata rather than all repositories.

That said, perhaps enough people has been confused by this to make some
kind of improvement motivated.


Let leave yum as is, but let try to redefine this behavior for dnf:
https://bugzilla.redhat.com/show_bug.cgi?id=1052020

Mirek
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

COPR - conclusion

[Miroslav Suchy]

Hi,
based on your feedback I decided to go with current code and integrate 
Koji as backend for Copr later.


I see three main reasons:

* A lot of you disagree with OBS. And no one is really excited from OBS.

* I'm the only full time developer of Copr; there is no community around 
OBS in Fedora. If something happen to me, there is no replacement and 
the project will probably stay in zombie state for quite long. If such 
issue happen with Copr+Koji, the changes will stay in Koji and rel-eng 
team can continue with development.


* OBS and Koji is soo much different (although I think OBS is superior). 
It really does not have sense to have two such different build systems 
for long term. And I do not think I can persuade Fedora Infrastructure 
team in long term to switch to OBS for main Fedora.


On the other hand, I do not think we can close the gap between Copr/Koji 
and OBS now nor in future as OBS have more resources. So I will try to 
get (in spare time) OBS to Fedora anyway and build some community around 
it. And revisit the decision in two-three years.
If you are willing to help me with packaging of OBS and get there some 
Fedora stuff (e.g mock) please ping me off-list.


Right now I want to get current Copr out of the door as soon as possible.
* which means package it, so it can be easily upgradable (frontend, cli 
are done, backend is on the way).

* give backend more disk space
* add chroots for building SCL
I hope that I can do that during September. And I expect release during 
October.


After this release I plan to work with mikem on integration with Koji, 
which will last those 7 months, so around Spring 2014 we can roll out 
version with Koji as backend.


If you want to help me with Copr you are more then welcome. See
  https://fedorahosted.org/copr/
for mailing list address and git repository.

Mirek

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 schedule: what would you do with more time?

[Miroslav Suchy]

On 08/22/2013 06:47 PM, Kevin Fenzi wrote:

Well, I noticed the rebuild was running only some times. I assume when
they were there to launch the builds in that batch?

Is there any way all the builds could be listed and just fired off and
queued all at once?


Peter queue honor build requires (Dennis script for mass rebuilds does 
not) so if some build fail, the queue is heavily reduced or stopped at 
all. This last until the failed build is manually resolved.
Firing off all builds at once will not help, because they would fail 
anyway due missing build requires.


Mirek (who just sit beside Petr, so I coincidentally know about it)
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F18, koji and IPv6

[Miroslav Suchy]

On 10.8.2012 19:15, Kevin Fenzi wrote:

Just as a side note, even if this was applied to our koji, there is
currently no ipv6 connectivity at the datacenter it's at, so you would
still be unable to connect to it with ipv6. ;(


You can be in IPv6 only network and connect via IPv6-IPv4 Proxy, which 
allow you to reach IPv4 world.


Mirek
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: As we develop SELinux we are adding new labels to homedir content

[Miroslav Suchy]

On 31.5.2012 21:44, Daniel J Walsh wrote:

A third option would be to run restorecon -R -v $HOME in background in an
profile script the first time you login on a new OS Version.  This would seem
to be the least time consuming, but could be subject to race conditions, you
hit the mislabeled file before the restorecon fixes it.  This would be better
then what we have now, in that everyone can hit the mislabeled file directory.


I mostly prefer latency on my workstation/latency and waiting for 
relabel is PITA. I would rather risk reboot if I ever hit that race 
condition (chance is 0.0001%?).

But on (production) server I would not mind waiting for relabeling.

I would propose to relabel in background by default (honestly my mother 
does not care about SElinux) and if user knows and care - as sysadmin of 
server - he will flip some option in /etc/selinux/config just before 
reboot and relabeling will be done in foreground as is done today with 
/.autorelabel


Mirek
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 18 Release name voting and Poll for whether to continue naming releases

[Miroslav Suchy]

On 25.4.2012 15:05, Peter Jones wrote:

On 04/24/2012 05:14 AM, Miroslav Suchý wrote:


I can keep only 3-5last releases in my poor head.


Then just *don't*. F14 is the past. Let it go.


Tell it to Mythdora which is based on Fedora Cambridge.

Or RaspberryPi remix which is based on Fedora Laughlin.

And many others. Fedora is not isolated world.

Mirek


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel