Re: Urgent attention required; ImageMagick update breakage

[Adam Williamson]

On Thu, 2017-08-24 at 08:40 +0200, Christian Dersch wrote:
> Hi all,
> 
> afaik these updates should be unpushed in stable releases ASAP, left
> negative karma now. Maybe I should just press the unpush button?

It's been done by karma now.

It looks to me like a 6.9.9 was released at the same time as 7.0.6,
which likely contains the necessary security fixes without any
backwards incompatibility. I've left a comment suggesting that be sent
out as an update instead of 7.0.6.
-- 
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

Re: Cleaning up the test-* namespaces

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, 2017-08-23 at 20:43 +0200, Pierre-Yves Chibon wrote:
> Good Morning Everyone,
> 
> A while ago we had the question about including tests in dist-git. We
> considered
> two options:
> - Have the tests in the same git repos as the files to generate the
> artifact
> - Have the tests in a separate namespace test-
> 
> While we weren't quite sure what was the best approach, we put in
> place a
> mechanism to automatically create the project in the test-* namespace
> when it
> was created in the regular namespace and using the same ACLs.
> 
> To be more concrete, we had the mechanism that was creating for every
> repository
> in the `rpms` namespace a corresponding repository in the `test-rpms` 
> namespace
> with the same maintainers and ACLs.
> 
> The recent work going on around CI [1] has led to the decision that
> tests stored
> in dist-git will be held in the same git repository as the spec files
> (for rpms).
> 
> Now some numbers:
> * We have currently 43663 repositories in dist-git
> grep 'repo ' gitolite.conf |wc -l
> 43663
> * 20843 of them correspond to the test-* namespaces
> grep 'repo test-' gitolite.conf |wc -l
> 20843
> * Leaving 22820 repositories not in the test-* namespaces
> grep 'repo ' gitolite.conf |grep -v 'repo test-' |wc -l
> 22820
> (I double checked, 20843+22820=43663 so we're good there)
> 
> I would like to get ride of the test-* namespaces. Tim Flink for
> which we
> originally added this mechanism agrees with it. We also have backups
> in case there
> is something needed from there sometime in the future.
> 
> Before I do so, I would like to know if anyone is opposed to this
> idea of
> removing the test-* namespaces from dist-git?
I only support this decision! 😉

IMO all tests should live either in rpms/$pkg or module/$module repos,
it doesn't make any sense to keep tests out. This also complicates life
when you update package and you want to change test at the same time.
> 
> 
> Thanks in advance for your help,
> Pierre
> 
> [1] http://fedoraproject.org/wiki/CI
> ___
> devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
> To unsubscribe send an email to devel-announce-leave@lists.fedoraproj
> ect.org
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlmedcsACgkQaVcUvRu8
X0zOURAApOEsrxpY6fM8E9zn8pwayLgGhdYp8YIGOLqcb+whxJbHPazsuX7m2108
YHFC3akTCloMGA8NkgaGYs/2m2XqbPYt5JXZqxV5O75NVKyWORqHac4c8oUDRJ17
PRlq+NqQY3Z6XbY9p76MZnYvyGTmUxWahBbMmLqU8/vVrdVlWJ1k5YcC099OR6GX
We1FEI/f/tPEJD5X0tNuO8lBZBzpZDnV30L2hDws/R4m1G6vNc1LF29qREZSzL25
WnGXbHn5FHsF4Iy4+dFV4U2PZ47n9XSTprquAqEsKTw7JwP3Re1+kuE986NTe//a
eoJ2dCelSkXwIzyav2alNjznoSsXeTHF8fUiQwK9UlDqVOZZ0zkOUNVEQu/ZyJ+d
xXiRV3II95NTplki/Z1iAahzlte/eFmRXC5RTO23mrMMk5oOuVaO+/k3Gl4Pg5Vl
pMoUaBuItwOPu/d0daaByhI2IKBsAU2rXfpteP4qRxJWmvFZvIf1IU1882oHOvy9
oPYDSm22omshwSn8NbEtfwUeLBpSCAJlRJBgvIMR3Fnw5Ux+5j8c+vZwqzQRnt6Q
IAvXlSQ6nA3SrDtXrke5aVN/tfsfhRJsO6mpe0qGn4iiVK88Ow1DOnwBpbzzhLgm
ev//qCjq/8zFX0kzuBmkI/HPGJAq+m+GQKjmqVouJDytF0EMycE=
=CqNk
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Urgent attention required; ImageMagick update breakage

[Christian Dersch]

Hi all,

afaik these updates should be unpushed in stable releases ASAP, left
negative karma now. Maybe I should just press the unpush button?

Greetings,
Christian


On 08/24/2017 05:16 AM, Michael Cronenworth wrote:
> Hi all,
>
> An ImageMagick update (6.9 => 7.0) with an SONAME bump and other
> breakage has been pushed to F25 and higher.
>
> First, the update introduces regressions on s390x and ppc64 arches.
> - https://bugzilla.redhat.com/show_bug.cgi?id=1484578
> - https://bugzilla.redhat.com/show_bug.cgi?id=1484579
>
> Secondly, rebuilds are required for:
>
>   autotrace-0.31.1-44.fc26.src.rpm
>   converseen-0.9.6.2-1.fc27.src.rpm
>   dmtx-utils-0.7.4-2.fc27.src.rpm
>   drawtiming-0.7.1-20.fc26.src.rpm
> F gtatool-2.2.0-4.fc27.src.rpm
>   imageinfo-0.05-25.fc26.src.rpm
>   inkscape-0.92.1-5.20170510bzr15686.fc27.src.rpm
>   kxstitch-1.2.0-7.fc26.src.rpm
>   perl-Image-SubImageFind-0.03-11.fc27.src.rpm
>   pfstools-2.0.6-1.fc27.src.rpm
> F php-magickwand-1.0.9.2-9.fc24.src.rpm
> F php-pecl-imagick-3.4.3-0.3.RC1.fc26.src.rpm
>   psiconv-0.9.8-20.fc26.src.rpm
>   q-7.11-27.fc27.src.rpm
>   ripright-0.11-3.fc26.src.rpm
>   rss-glx-0.9.1.p-29.fc26.src.rpm
> F rubygem-rmagick-2.16.0-3.fc26.src.rpm
> F synfig-1.2.0-5.fc27.src.rpm
>   (boost issues)
> F synfigstudio-1.1.10-0.20160706gitd4e547.fc25.src.rpm
>   (needs synfig)
>   vdr-scraper2vdr-1.0.5-2.20170611git254122b.fc27.src.rpm
>   vips-8.5.6-1.fc27.src.rpm
>   WindowMaker-0.95.8-1.fc27.src.rpm
> F cuneiform
>   (some c++ blowup)
>   k3d
>
> The ones with F have possible compile issues.
>
> Thirdly, two updates have been created. I've disabled autopush on them.
> - https://bodhi.fedoraproject.org/updates/FEDORA-2017-0a1f3de4eb
> - https://bodhi.fedoraproject.org/updates/FEDORA-2017-c276ee400a
>
> It is really late here and I don't have the time to investigate the
> arch issues right now. I'll investigate when I can.
> ___
> 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

Cleaning up the test-* namespaces

[Pierre-Yves Chibon]

Good Morning Everyone,

A while ago we had the question about including tests in dist-git. We considered
two options:
- Have the tests in the same git repos as the files to generate the artifact
- Have the tests in a separate namespace test-

While we weren't quite sure what was the best approach, we put in place a
mechanism to automatically create the project in the test-* namespace when it
was created in the regular namespace and using the same ACLs.

To be more concrete, we had the mechanism that was creating for every repository
in the `rpms` namespace a corresponding repository in the `test-rpms` namespace
with the same maintainers and ACLs.

The recent work going on around CI [1] has led to the decision that tests stored
in dist-git will be held in the same git repository as the spec files (for 
rpms).

Now some numbers:
* We have currently 43663 repositories in dist-git
grep 'repo ' gitolite.conf |wc -l
43663
* 20843 of them correspond to the test-* namespaces
grep 'repo test-' gitolite.conf |wc -l
20843
* Leaving 22820 repositories not in the test-* namespaces
grep 'repo ' gitolite.conf |grep -v 'repo test-' |wc -l
22820
(I double checked, 20843+22820=43663 so we're good there)

I would like to get ride of the test-* namespaces. Tim Flink for which we
originally added this mechanism agrees with it. We also have backups in case 
there
is something needed from there sometime in the future.

Before I do so, I would like to know if anyone is opposed to this idea of
removing the test-* namespaces from dist-git?


Thanks in advance for your help,
Pierre

[1] http://fedoraproject.org/wiki/CI
___
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: modularity: (my) expectations vs. reality

[Tomas Tomecek]

On Wed, Aug 23, 2017 at 6:16 PM, stan  wrote:

> On Wed, 23 Aug 2017 07:51:57 +0200
> Michal Novotny  wrote:
>
> > I guess I am missing something but I don't see how modularity adds
> > flexibility. rpm, yum repos, ansible, dnf seem to be quite flexible
> > even now and having that + something else on top seems to be less
> > flexible. I am just speaking my mind here.
>
> I'm not involved in modularity, and I'm speaking as an observer.  But
> it seems that it would be a lot more effective to put the libraries in
> containers, and keep applications in rpms.
>
> That is, say there is a python container, and it contains the various
> formats of python, 2.6, 2.7, 3.5, 3.6, etc.  Then any application that
> needs python just specifies the python it needs, and the OS links it
> with the proper library from the container when it runs.
>

​We would need to develop a dedicated, non-trivial tooling to enable this
functionality.​ And honestly, I can't even imagine how this could be even
possible to implement for all ecosystems (compiled languages, interpreted
languages).


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

Re: CI projects in Copr

[Pavel Raiskup]

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.

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

Re: ImageMagick Unresponsive Maintainer process - hubbitus (Pavel Alexeev)

[Remi Collet]

Le 24/08/2017 à 02:32, Moez Roy a écrit :

> The soname bump requires packages that depend on it need to be rebuilt, so
> I updated ImageMagick to 7.0.6-9.


Such a version bump in stable branch is not acceptable.

ImageMagick 7 removed lot of functions (deprecated in v6)

Especially as ImageMagick 6 is still maintained.

BTW, latest version 6.9.9-9 also have some API changes

- 6.9.6-8 => bump to .3
- 6.9.7-6 => bump to .4
- 6.9.9-0 => bump to .5

Yes, this package is a nightmare.


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

Urgent attention required; ImageMagick update breakage

[Michael Cronenworth]

Hi all,

An ImageMagick update (6.9 => 7.0) with an SONAME bump and other breakage has been 
pushed to F25 and higher.


First, the update introduces regressions on s390x and ppc64 arches.
- https://bugzilla.redhat.com/show_bug.cgi?id=1484578
- https://bugzilla.redhat.com/show_bug.cgi?id=1484579

Secondly, rebuilds are required for:

  autotrace-0.31.1-44.fc26.src.rpm
  converseen-0.9.6.2-1.fc27.src.rpm
  dmtx-utils-0.7.4-2.fc27.src.rpm
  drawtiming-0.7.1-20.fc26.src.rpm
F gtatool-2.2.0-4.fc27.src.rpm
  imageinfo-0.05-25.fc26.src.rpm
  inkscape-0.92.1-5.20170510bzr15686.fc27.src.rpm
  kxstitch-1.2.0-7.fc26.src.rpm
  perl-Image-SubImageFind-0.03-11.fc27.src.rpm
  pfstools-2.0.6-1.fc27.src.rpm
F php-magickwand-1.0.9.2-9.fc24.src.rpm
F php-pecl-imagick-3.4.3-0.3.RC1.fc26.src.rpm
  psiconv-0.9.8-20.fc26.src.rpm
  q-7.11-27.fc27.src.rpm
  ripright-0.11-3.fc26.src.rpm
  rss-glx-0.9.1.p-29.fc26.src.rpm
F rubygem-rmagick-2.16.0-3.fc26.src.rpm
F synfig-1.2.0-5.fc27.src.rpm
  (boost issues)
F synfigstudio-1.1.10-0.20160706gitd4e547.fc25.src.rpm
  (needs synfig)
  vdr-scraper2vdr-1.0.5-2.20170611git254122b.fc27.src.rpm
  vips-8.5.6-1.fc27.src.rpm
  WindowMaker-0.95.8-1.fc27.src.rpm
F cuneiform
  (some c++ blowup)
  k3d

The ones with F have possible compile issues.

Thirdly, two updates have been created. I've disabled autopush on them.
- https://bodhi.fedoraproject.org/updates/FEDORA-2017-0a1f3de4eb
- https://bodhi.fedoraproject.org/updates/FEDORA-2017-c276ee400a

It is really late here and I don't have the time to investigate the arch issues 
right now. I'll investigate when I can.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: ImageMagick Unresponsive Maintainer process - hubbitus (Pavel Alexeev)

[Michael Cronenworth]

On 08/23/2017 07:32 PM, Moez Roy wrote:
The soname bump requires packages that depend on it need to be rebuilt, so I 
updated ImageMagick to 7.0.6-9.


I tagged this update now  for Updates Testing for f25 & f26 as it is an urgent 
fix.

It is also in build root override so affected packages can now be rebuilt.


Also, this is a huge no-no.

From ImageMagick.spec:
# https://bugzilla.redhat.com/show_bug.cgi?id=1484578 & 
https://bugzilla.redhat.com/show_bug.cgi?id=1484579

ExcludeArch: s390x ppc64

Other packages build for those arches and now cannot be built because there is no 
ImageMagick package available now.

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

Re: ImageMagick Unresponsive Maintainer process - hubbitus (Pavel Alexeev)

[Michael Cronenworth]

On 08/23/2017 07:32 PM, Moez Roy wrote:


The soname bump requires packages that depend on it need to be rebuilt, so I 
updated ImageMagick to 7.0.6-9.


I tagged this update now  for Updates Testing for f25 & f26 as it is an urgent 
fix.

It is also in build root override so affected packages can now be rebuilt.


What you have done is out of line.

You've pushed a change that breaks packages and are dumping the work on others?

You've created an update with autopush enabled with only 1 positive karma required 
with -99 negative karma?


This is not appropriate behavior for releasing updates.

I have broken builds now that I'll have to spend time fixing.

I'm disabling autopush on your updates until rebuilds can be done. Please do not 
enable it.

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

Re: COPR strategy

[Rudolf Kastl]

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.

kind regards,
Rudolf Kastl



2017-08-22 17:15 GMT+02:00 Kamil Dudka :

> On Tuesday, August 22, 2017 5:03:06 PM CEST Michal Novotny wrote:
> > On Tue, Aug 22, 2017 at 4:40 PM, Kamil Dudka  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 
> 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.
>
> OK.  Thank you for working on it!  I am looking forward to use it one
> day...
>
> > > 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: No i686 build of grub2?

[Kevin Kofler]

Peter Jones wrote:
> It is still built as grub2-pc{,-modules}, just built a bit differently.

It is not. There is no grub2-pc in dist-git, and grub2 has this ExcludeArch:
http://pkgs.fedoraproject.org/rpms/grub2/blob/master/f/grub2.spec#_57

It is not enough to build the 32-bit PC/BIOS grub2 on x86_64, it has to be 
built on i686 too to be in the i686 repo.

Ideally, you would also support the 32-bit UEFI and even 64-bit UEFI 
binaries on the i686 distro, but at the very least, the BIOS version that 
was always there needs to be built again.

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

Re: [modularity] Modularizing the world fast and iteratively

[Kevin Kofler]

Adam Samalik wrote:
> all their dependencies, we need to build them. But, for example, a pretty
> commonly needed thing like autotools [3] has pretty crazy build
> dependencies [4] including Java, gtk2, gtk3, erlang, X11, python2,
> python3, etc.

This is exactly why the separate Core and Extras were such a PITA and why 
the Core-Extras Merge was done. Doing the opposite now is a BAD idea.

Modularity may sound great on paper, but as soon as you actually try to 
implement it, it falls apart like a house of cards.

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

Re: Platform Python changes and python3dist tags

[Scott Talbert]

On Tue, 22 Aug 2017, Scott Talbert wrote:


Hi,

I was just trying to build a new package in Rawhide that built fine a few 
days ago.  The failure seems to be occurring because the python3 
setuptools_scm module isn't being found.  I'm using the new pythonXdist 
tags:


BuildRequires:  %{py2_dist py pytest setuptools_scm}
BuildRequires:  %{py3_dist py pytest setuptools_scm}

It seems this is causing several of the recently added platform-python
packages to be pulled in:
Installing:
platform-python-pytestnoarch3.2.1-2.fc28   fedora 438 
k

platform-python-setuptools_scmnoarch1.15.6-4.fc28  fedora 36 k

Both the python3-setuptools_scm and platform-python-setuptools_scm packages 
have the python3dist tag:


$ rpm -q --provides -p 
platform-python-setuptools_scm-1.15.6-4.fc28.noarch.rpm
warning: platform-python-setuptools_scm-1.15.6-4.fc28.noarch.rpm: Header V3 
RSA/SHA256 Signature, key ID 9db62fb1: NOKEY

platform-python-setuptools_scm = 1.15.6-4.fc28
python3.6dist(setuptools-scm) = 1.15.6
python3dist(setuptools-scm) = 1.15.6

$ rpm -q --provides -p python3-setuptools_scm-1.15.6-4.fc28.noarch.rpm
warning: python3-setuptools_scm-1.15.6-4.fc28.noarch.rpm: Header V3 
RSA/SHA256 Signature, key ID 9db62fb1: NOKEY

python3-setuptools_scm = 1.15.6-4.fc28
python3.6dist(setuptools-scm) = 1.15.6
python3dist(setuptools-scm) = 1.15.6
[swt2c@rawhide-test ~][PROD]$

It seems that probably the platform-python packages shouldn't have these 
tags?


I'm hearing a lot of crickets.

I filed https://bugzilla.redhat.com/show_bug.cgi?id=1484607 against rpm as 
I didn't see any obvious way for the platform-python packages to exclude 
themselves from the python3dist provides.


I'm just going to stop using the py3_dist stuff for now.

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

Re: ImageMagick Unresponsive Maintainer process - hubbitus (Pavel Alexeev)

[Moez Roy]

On Mon, Jul 31, 2017 at 12:13 PM, Kevin Fenzi  wrote:

> ok, I rebuilt the following ones. The ones with F next to them failed to
> build:
>
>   autotrace-0.31.1-44.fc26.src.rpm
>   converseen-0.9.6.2-1.fc27.src.rpm
>   dmtx-utils-0.7.4-2.fc27.src.rpm
>   drawtiming-0.7.1-20.fc26.src.rpm
> F gtatool-2.2.0-4.fc27.src.rpm
>   imageinfo-0.05-25.fc26.src.rpm
>   inkscape-0.92.1-5.20170510bzr15686.fc27.src.rpm
>   kxstitch-1.2.0-7.fc26.src.rpm
>   perl-Image-SubImageFind-0.03-11.fc27.src.rpm
>   pfstools-2.0.6-1.fc27.src.rpm
> F php-magickwand-1.0.9.2-9.fc24.src.rpm
> F php-pecl-imagick-3.4.3-0.3.RC1.fc26.src.rpm
>   psiconv-0.9.8-20.fc26.src.rpm
>   q-7.11-27.fc27.src.rpm
>   ripright-0.11-3.fc26.src.rpm
>   rss-glx-0.9.1.p-29.fc26.src.rpm
> F rubygem-rmagick-2.16.0-3.fc26.src.rpm
> F synfig-1.2.0-5.fc27.src.rpm
>   (boost issues)
> F synfigstudio-1.1.10-0.20160706gitd4e547.fc25.src.rpm
>   (needs synfig)
>   vdr-scraper2vdr-1.0.5-2.20170611git254122b.fc27.src.rpm
>   vips-8.5.6-1.fc27.src.rpm
>   WindowMaker-0.95.8-1.fc27.src.rpm
> F cuneiform
>   (some c++ blowup)
>   k3d
>
> With that I think rawhide should be back on track.
>
> If all looks well for a bit I guess I can try and do f25/f26.
>
> kevin
>
>
>
>

The soname bump requires packages that depend on it need to be rebuilt, so
I updated ImageMagick to 7.0.6-9.

I tagged this update now  for Updates Testing for f25 & f26 as it is an
urgent fix.

It is also in build root override so affected packages can now be rebuilt.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Self Introduction: Charlie Sale

[Charlie Sale]

Hello Fedora Community!

My name is Charlie Sale and I am an amateur C and C++ developer. I've been
programming for about 4 years now and have produced a variety of projects.
I am now releasing my first large-scale distributed project on the Fedora
project. I have submitted my package review at
https://bugzilla.redhat.com/show_bug.cgi?id=1484164 . Please give me a
shot. I very involved in my project and intend to maintain it with
diligence. I am also in need of a sponsor, so if you are interested, please
help me out.

I am looking forward to joining the package maintainer's community.

Regards,

Charlie
-- 

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

Fedora Rawhide-20170823.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Server dvd i386
Workstation live i386
Server boot i386
Kde live i386

Failed openQA tests: 32/137 (x86_64), 1/2 (arm)

New failures (same test did not fail in Rawhide-20170822.n.0):

ID: 133549  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/133549
ID: 133551  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/133551
ID: 133555  Test: x86_64 Workstation-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/133555
ID: 133556  Test: x86_64 Workstation-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/133556
ID: 133557  Test: x86_64 Workstation-dvd_ostree-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/133557
ID: 133569  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/133569
ID: 133621  Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/133621

Old failures (same test failed in Rawhide-20170822.n.0):

ID: 133502  Test: x86_64 Server-dvd-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/133502
ID: 133509  Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/133509
ID: 133511  Test: x86_64 Server-dvd-iso server_cockpit_default
URL: https://openqa.fedoraproject.org/tests/133511
ID: 133515  Test: x86_64 Server-dvd-iso server_role_deploy_database_server
URL: https://openqa.fedoraproject.org/tests/133515
ID: 133523  Test: x86_64 Workstation-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/133523
ID: 133525  Test: x86_64 Workstation-live-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/133525
ID: 133542  Test: x86_64 KDE-live-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/133542
ID: 133546  Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/133546
ID: 133550  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/133550
ID: 133566  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/133566
ID: 133567  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/133567
ID: 133568  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/133568
ID: 133570  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/133570
ID: 133571  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/133571
ID: 133572  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/133572
ID: 133573  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/133573
ID: 133574  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/133574
ID: 133575  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/133575
ID: 133576  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/133576
ID: 133578  Test: x86_64 universal install_shrink_ext4
URL: https://openqa.fedoraproject.org/tests/133578
ID: 133579  Test: x86_64 universal install_shrink_ntfs
URL: https://openqa.fedoraproject.org/tests/133579
ID: 133584  Test: x86_64 universal support_server
URL: https://openqa.fedoraproject.org/tests/133584
ID: 133633  Test: x86_64 universal upgrade_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/133633
ID: 133634  Test: x86_64 universal install_rescue_encrypted
URL: https://openqa.fedoraproject.org/tests/133634
ID: 133635  Test: x86_64 universal install_rescue_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/133635
ID: 133723  Test: x86_64 Server-dvd-iso support_server
URL: https://openqa.fedoraproject.org/tests/133723

Soft failed openQA tests: 5/137 (x86_64)
(Tests completed, but using a workaround for a known bug)

New soft failures (same test did not soft fail in Rawhide-20170822.n.0):

ID: 133521  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/133521
ID: 133538  Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/133538
ID: 133539  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/133539

Old soft failures (same test soft failed in Rawhide-20170822.n.0):

ID: 133585  Test: x86_64 universal install_repository_http_variation
URL: https://openqa.fedoraproject.org/tests/133585
ID: 133717  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/133717

Passed o

Re: introducing fed-install: easy way to install packages from koji and other releases

[Kevin Fenzi]

On 08/23/2017 01:17 AM, Tomas Tomecek wrote:
> 
> 
> On Sun, Aug 20, 2017 at 10:59 PM, Kevin Fenzi  > wrote:
> 
> 
> First, one thing that would be very handy (but could perhaps just be a
> dnf plugin) is to install from koji, but use signed packages (if
> available). I'm not sure how hard it would be to implement in your tool,
> but you might take a look if you are interested.
> 
> 
> What would be the place to pick the signed packages from?

If there is a written out signed rpm you can find it at (for example):

https://kojipkgs.fedoraproject.org/packages/fedrepo-req/1.5.0/2.fc28/data/signed/9db62fb1/noarch/fedrepo-req-1.5.0-2.fc28.noarch.rpm

These are culled when they are no longer tagged into active release
tags, but if they are recent enough there should be a written out signed
rpm.

> I think this is a great suggestion​. The reason it's implemented like
> this is because I had no idea where to get those signed packages.

koji download-build also has a option to download signed packages:

  --key=KEY Download rpms signed with the given key


> Secondly, I think this could indeed be handy for folks running rawhide
> or branched, but I worry about people on stable releases mistakenly
> using it and upgrading a chunk of their install to rawhide when they
> didn't realize it would do that. Not sure how to prevent that though,
> perhaps a warning in some cases?
> 
> 
> I like this suggestion. I opened an upstream issue for that:
> 
> https://github.com/TomasTomecek/fed-install/issues/3

Thanks!

kevin




signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Self Introduction: Richard Kellner

[Richard Kellner]

Hello everyone,

my name is Richard Kellner and I am a Python developer. In my free time, I
am also a PyCon SK volunteer. Recently I have got this crazy idea to submit
some of my packages to Fedora, so here I am. I have just submitted my first
package for review: https://bugzilla.redhat.com/show_bug.cgi?id=1484561
hopefully several more will come soon.

Looking forward to becoming part of the Fedora community.

Regards,

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

Re: [modularity] Modules and AppStream

[Owen Taylor]

On Wed, 2017-08-23 at 17:25 +0100, Richard Hughes wrote:
> On 23 August 2017 at 13:57, Marius Vollmer  wrote:
> > In a modular repository, I think the same thing should happen so that
> > GNOME Software can present interesting modules to the user in a nice
> > way.
> 
> What kind of modules would be shown in gnome-software? Are
> applications like Firefox going to be supported in the new modularity
> system? We're not going to be showing httpd there for instance.

The current expectation is that the only way that modules are going to
show up in GNOME Software is when they are safely wrapped up as a Flatpak.
Because un-encapsulated modules can't be arbitrarily mixed and combined,
displaying them to users would add a huge amount of complexity.

> >  - Metainfo is in packages, but we need to be installing modules.
> 
> How are we going to be installing modules in a modular-system?
> PackageKit is only going to be able to install packages so
> gnome-software will obviously need to be able to install things.

Via flatpak, not via PackageKit. :-)

> >  Thus,
> >the collection data needs to have module names into the AppStream
> > tag.
> 
> I think the pkgname tag needs to contain the package name. We have a
>  tag that might be more suitable for adding things like
> version or stream information.

yeah, the appstream provided via registry.fedoraproject.org  will have what to
install in the  tag.

> >  I propose to keep AppStream metainfo data in
> >packages, and map from package names to module names during
> >construction of the collection data.
> 
> Can you elaborate a bit? At the moment in Fedora we generate the
> AppStream metadata from a mirror of all the packages using
> appstream-builder.

appstream for modules is something that Marius is going to have to 
eloborate on :-) For the desktop, the appstream data will be collected
from the Flatpaks uploaded to registry.fedoraproject.org and made available
for download.

> >  - Because of streams and profiles, there can be multiple versions of
> >metainfo for a given AppStream component id.  These need to be
> >merged
> 
> No, I don't think they do. If you have two very different versions of
> Firefox (one LTS, one bleeding edge) you want a different description,
> different screenshots and different reviews.
> 
> The way we've solved this in Flatpak is to use a different application
> ID, for instance Firefox nightly would be
> org.mozilla.Firefox.Nightly.desktop rather than
> org.mozilla.Firefox.desktop
> 
> I don't think you can pretend that applications from different
> branches (with different features, bugs and possibly UI) are the
> "same" component, especially when you can install zero, one or many at
> the same time.

The Flatpak build tooling currently enforces that the branch is the same
as the module stream, but allows the packager to use different IDs for
different streams if they want - so they can have a nightly and a stable
stream that can be parallel installed as above. (With caveats of needing
to modify application code appropriately.)

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

Re: Review swap

[Andrea Musuruane]

Hi Volerk,

Hello Andrea!
>
> Please add it to http://fedoraproject.org/wiki/GIS
>

Added!!

Bye,

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

Re: Review swap

[Volker Fröhlich]

Am 2017-08-23 um 12:16 schrieb Andrea Musuruane:

Hi!
 I'm looking for a reviewer for

osmctools - Tools to manipulate OpenStreetMap files:
https://bugzilla.redhat.com/show_bug.cgi?id=1464777

Maybe some other OSM mapper is interested?

I'm happy to exchange reviews.

Thanks in advance.

Bye,

Andrea



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



Hello Andrea!

Please add it to http://fedoraproject.org/wiki/GIS

Greetings,

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

Re: autoconf-archive suddenly gone in EPEL 7

[Benjamin Kircher]

> On 23. Aug 2017, at 14:29, Stephen Gallagher  wrote:
> 
> This is one of those unfortunate things that happens when using CentOS; major 
> releases trail RHEL and sometimes when things make the shift from EPEL to 
> RHEL proper, CentOS users end up without some packages available for a while. 
> We're dealing with the same issue with the `http-parser` package, which not 
> only got moved from EPEL to RHEL, but also downgraded the NVR in the process 
> (so we can't just leave the EPEL package in the repo  until CentOS catches 
> up).

First time this has bitten me. To be honest, this is actually pretty bad. 
(Understandable though.)

Luckily, 7.4.1708 is expected somewhere between Aug 22 and Sept 12 according to 
[1].

BK

[1] 
https://seven.centos.org/2017/08/centos-linux-7-1708-based-on-rhel-7-4-source-code/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [modularity] Modules and AppStream

[Richard Hughes]

On 23 August 2017 at 13:57, Marius Vollmer  wrote:
> In a modular repository, I think the same thing should happen so that
> GNOME Software can present interesting modules to the user in a nice
> way.

What kind of modules would be shown in gnome-software? Are
applications like Firefox going to be supported in the new modularity
system? We're not going to be showing httpd there for instance.

>  - Metainfo is in packages, but we need to be installing modules.

How are we going to be installing modules in a modular-system?
PackageKit is only going to be able to install packages so
gnome-software will obviously need to be able to install things.

>  Thus,
>the collection data needs to have module names into the AppStream
> tag.

I think the pkgname tag needs to contain the package name. We have a
 tag that might be more suitable for adding things like
version or stream information.

>  I propose to keep AppStream metainfo data in
>packages, and map from package names to module names during
>construction of the collection data.

Can you elaborate a bit? At the moment in Fedora we generate the
AppStream metadata from a mirror of all the packages using
appstream-builder.

>  - Because of streams and profiles, there can be multiple versions of
>metainfo for a given AppStream component id.  These need to be
>merged

No, I don't think they do. If you have two very different versions of
Firefox (one LTS, one bleeding edge) you want a different description,
different screenshots and different reviews.

The way we've solved this in Flatpak is to use a different application
ID, for instance Firefox nightly would be
org.mozilla.Firefox.Nightly.desktop rather than
org.mozilla.Firefox.desktop

I don't think you can pretend that applications from different
branches (with different features, bugs and possibly UI) are the
"same" component, especially when you can install zero, one or many at
the same time.

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

Re: modularity: (my) expectations vs. reality

[stan]

On Wed, 23 Aug 2017 07:51:57 +0200
Michal Novotny  wrote:

> I guess I am missing something but I don't see how modularity adds
> flexibility. rpm, yum repos, ansible, dnf seem to be quite flexible
> even now and having that + something else on top seems to be less
> flexible. I am just speaking my mind here.

I'm not involved in modularity, and I'm speaking as an observer.  But
it seems that it would be a lot more effective to put the libraries in
containers, and keep applications in rpms.

That is, say there is a python container, and it contains the various
formats of python, 2.6, 2.7, 3.5, 3.6, etc.  Then any application that
needs python just specifies the python it needs, and the OS links it
with the proper library from the container when it runs.

Or, gtk, with all its variations in a container, and again, applications
get the version they need to run transparently.

This would eliminate all the redundant library duplication that
containers as they are now envisioned would entail.  There would still
be redundancy, but it would be the minimal set for the applications that
are installed.  And it would still allow the upstream of applications to
specify specific libraries without worrying about
variations in distributions.  

This doesn't address security concerns if an application upstream
specifies a library that is known to be insecure or unmaintained, and
it is in a container.  But that's just a policy decision of a
distribution as to whether they allow a library container to contain
insecure versions in order to permit applications to install.

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

Re: removable setup rpm?!

[Miroslav Suchý]

Dne 18.8.2017 v 13:43 Petr Stodulka napsal(a):

which leads to unusable system, because of missing important files,
like /etc/shadow, 


Lets just focus on this one package. The question is why the removal of the 
package is removing
  /etc/shadow
  /etc/passwd
?

When I remove it it will:
warning: /etc/shadow saved as /etc/shadow.rpmsave
warning: /etc/passwd saved as /etc/passwd.rpmsave

That is because there is in spec file:

%verify(not md5 size mtime) %config(noreplace) /etc/passwd
%verify(not md5 size mtime) %config(noreplace) /etc/group

I would expect rather %ghost directive there.

With %ghost in place we can even omit the %posttrans:

#throw away useless and dangerous update stuff until rpm will be able to
#handle it ( http://rpm.org/ticket/6 )
%post -p 
for i, name in ipairs({"passwd", "shadow", "group", "gshadow"}) do
 os.remove("/etc/"..name..".rpmnew")
end

The initial content should be IMHO populated by anaconda.

With the %ghost the removal of package will leave the important files on disk 
and the system will be operational.

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

Re: No i686 build of grub2?

[Peter Jones]

On Wed, Aug 23, 2017 at 07:27:44AM -0500, Bruno Wolff III wrote:
> Currently grub2 isn't being built for i686 since somewhere between 2.02-8
> and 2.02-10.
> I looked through the change log (but not the git log yet) and didn't see
> anything mentioning this, which I would have expected if it was an
> intentional change.
> So is this a new permanent feature going forward or a temporary oops?
> (I still have one machine I use regularly, that only runs i686 and it will
> probably be a while before I can afford to replace it.)

It is still built as grub2-pc{,-modules}, just built a bit differently.
I'll figure out how to re-work it so you won't see a problem, thanks for
the heads up.

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

alglib soname bump

[Sandro Mani]

Hi

I'm updating to alglib-3.12.0 in rawhide and F27, I'll rebuild the 
following dependent packages:


gmsh-3.0.4-1.fc27.src.rpm
qmapshack-1.9.0-1.fc27.src.rpm


Sandro
___
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

[Alexander Ploumistos]

On Wed, Aug 23, 2017 at 3:00 PM, Miroslav Suchý  wrote:
> Dne 22.8.2017 v 14:53 Michal Novotny napsal(a):
>>
>> 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.
>>
>
> It is there waiting for your karma.

[facepalm]
I had seen the updates in bodhi, but for some reason I was waiting for
an fc27 update...

What are copr builders running by the way?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Complicated problem: kiwi and kiwi-gtk conflict

[Matthew Miller]

On Wed, Aug 23, 2017 at 09:42:29AM -0400, Neal Gompa wrote:
> It's both: http://suse.github.io/kiwi/development/kiwi_from_python.html
> It's explicitly designed to be used as a Python module as well as a
> command line tool.

Ok then. :)


-- 
Matthew Miller

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

Re: Complicated problem: kiwi and kiwi-gtk conflict

[Neal Gompa]

On Wed, Aug 23, 2017 at 9:39 AM, Matthew Miller
 wrote:
> On Wed, Aug 23, 2017 at 05:40:27AM -0400, Neal Gompa wrote:
>> So I submitted a review request on Sunday for python-kiwi[1], which is
>> the KIWI appliance image builder tool from SUSE[2] and is registered
>> in PyPI as kiwi[3].
>
> Shouldn't this new package just be named "kiwi"? From the docs, it's a
> command-line application that happens to be written in Python, not a
> Python module.
>

It's both: http://suse.github.io/kiwi/development/kiwi_from_python.html

It's explicitly designed to be used as a Python module as well as a
command line tool.

The older Perl-based one was the same way.


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

Re: Complicated problem: kiwi and kiwi-gtk conflict

[Matthew Miller]

On Wed, Aug 23, 2017 at 05:40:27AM -0400, Neal Gompa wrote:
> So I submitted a review request on Sunday for python-kiwi[1], which is
> the KIWI appliance image builder tool from SUSE[2] and is registered
> in PyPI as kiwi[3].

Shouldn't this new package just be named "kiwi"? From the docs, it's a
command-line application that happens to be written in Python, not a
Python module.

-- 
Matthew Miller

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

Re: Complicated problem: kiwi and kiwi-gtk conflict

[Neal Gompa]

On Wed, Aug 23, 2017 at 8:58 AM, Haïkel  wrote:
> 2017-08-23 14:44 GMT+02:00 Miroslav Suchý :
>> Dne 23.8.2017 v 11:40 Neal Gompa napsal(a):
>>>
>>> However, there's a problem. It seems python-kiwi already exists in
>>> Fedora[4], and it's the kiwi-gtk framework[5].
>>>
>>> I'm not sure what to do in this scenario. I've requested from upstream
>>> to rename the module[6], but I don't think they'll go for that,
>>> especially since they actually do have the kiwi name in PyPI.
>>>
>>> So what can I do?
>>
>>
>> Ask hguemar (owner of python-kiwi in fedora) to rename python-kiwi to
>> python-kiwi-gtk.
>>
>> Mirek
>
> Since it got renamed in pypi, ok, but Neal will have to review the
> renamed package.
>
> H.
>

Sure, I will. Just assign the rename request to me and I'll take a
crack at 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

Re: [modularity] Modularizing the world fast and iteratively

[Matthew Miller]

On Wed, Aug 23, 2017 at 09:54:25AM +0200, Adam Samalik wrote:
> So instead of trying to make everything perfect from the begining, we could
> build everything we need against the Bootstrap module - a module that is
> used as a buildroot for Host and Platform and contains mostly everything we
> need. To compare, there is a report without using bootstrap [5] and with
> using bootstrap [6]. This way we'll have a pretty decent set of module very
> soon.

I am +1 to a plan which yields a decent set of modules very soon. :)

Also, I'm continuing to feel good about this picture I drew several
years ago — https://mattdm.org/fedora/2015rings/ :)




-- 
Matthew Miller

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

Re: CI projects in Copr

[jkonecny]

Hi, 

We are making daily builds of Anaconda in Copr for Rawhide[1] and
actual Fedora[2]. These daily builds are used for our other test
suites.

[1]: https://copr.fedorainfracloud.org/coprs/g/rhinstaller/Anaconda/
[2]: https://copr.fedorainfracloud.org/coprs/g/rhinstaller/Anaconda-dev
el/

On Wed, 2017-08-23 at 13:46 +0200, 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: No i686 build of grub2?

[Neal Gompa]

On Wed, Aug 23, 2017 at 9:13 AM, Bruno Wolff III  wrote:
> On Wed, Aug 23, 2017 at 08:57:30 -0400,
>  Mauricio Tavares  wrote:
>>
>> I think I read here (or in other mailing list) about an interest in
>> dropping 32bit altogether. But this might be just my imagination.
>
>
> Certainly there was a discussion, but I hadn't heard this was definitive, or
> that it was going to start in f27. (I'm using f28, but the change happened
> to f27 builds around the branch time.) I would expect this actually being
> done to be worthy of an announcement. That's why I think this might be a
> temporary issue. But how I work around it will depend on whether on not
> there will be official i686 builds again soon.

That addition of %ix86 to the ExcludeArch should probably be dropped.
There was nothing that indicated that should have been added to begin
with.


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

Re: No i686 build of grub2?

[Bruno Wolff III]

On Wed, Aug 23, 2017 at 08:57:30 -0400,
 Mauricio Tavares  wrote:

I think I read here (or in other mailing list) about an interest in
dropping 32bit altogether. But this might be just my imagination.


Certainly there was a discussion, but I hadn't heard this was definitive, 
or that it was going to start in f27. (I'm using f28, but the change 
happened to f27 builds around the branch time.) I would expect this 
actually being done to be worthy of an announcement. That's why I think 
this might be a temporary issue. But how I work around it will depend 
on whether on not there will be official i686 builds again soon.

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

Re: No i686 build of grub2?

[Tom Hughes]

On 23/08/17 13:57, Vascom wrote:


This commit remove add i686 to ExcludeArch
https://src.fedoraproject.org/rpms/grub2/c/ecef1ed7b50ed05b65574c8b8815d7ae66e5a0a9
ExcludeArch: s390 s390x %{arm} %{?ix86}


Without of course the required comment pointing at the required bug 
which blocks the relevant tracker bugs:


https://fedoraproject.org/wiki/Packaging:Guidelines#Architecture_Build_Failures

and nothing on the tracker bug that I can see:

https://bugzilla.redhat.com/showdependencytree.cgi?id=F-ExcludeArch-x86&hide_resolved=1

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

[ANNOUNCE] D-Bus Broker Project

[David Herrmann]

This is the first public release of dbus-broker.

Git Tag: v3
Archive: 
https://github.com/bus1/dbus-broker/archive/v3/dbus-broker-v3.tar.gz

The dbus-broker project is an implementation of a message bus as
defined by the D-Bus specification. Its aim is to provide high
performance and reliability, while keeping compatibility to the D-Bus
reference implementation. It is exclusively written for linux systems,
and makes use of many modern features provided by recent linux kernel
releases. Details are discussed in its introductory blog post:

https://dvdhrm.github.io/rethinking-the-dbus-message-bus/

The project is still experimental and not meant for production use,
yet. Packages are available for Fedora and Arch Linux. Other
distributions will follow.

DETAILS:
https://github.com/bus1/dbus-broker/wiki

BUG REPORTS:
https://github.com/bus1/dbus-broker/issues

GIT:
g...@github.com:bus1/dbus-broker.git
https://github.com/bus1/dbus-broker.git

PACKAGES:
https://copr.fedorainfracloud.org/coprs/g/bus1/dbus/package/dbus-broker/
https://aur.archlinux.org/packages/dbus-broker
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Complicated problem: kiwi and kiwi-gtk conflict

[Haïkel]

2017-08-23 14:44 GMT+02:00 Miroslav Suchý :
> Dne 23.8.2017 v 11:40 Neal Gompa napsal(a):
>>
>> However, there's a problem. It seems python-kiwi already exists in
>> Fedora[4], and it's the kiwi-gtk framework[5].
>>
>> I'm not sure what to do in this scenario. I've requested from upstream
>> to rename the module[6], but I don't think they'll go for that,
>> especially since they actually do have the kiwi name in PyPI.
>>
>> So what can I do?
>
>
> Ask hguemar (owner of python-kiwi in fedora) to rename python-kiwi to
> python-kiwi-gtk.
>
> Mirek

Since it got renamed in pypi, ok, but Neal will have to review the
renamed package.

H.

> ___
> 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

[modularity] Modules and AppStream

[Marius Vollmer]

Hi,

what happens when the packages in a module contain AppStream metainfo
files?

In a non-modular repository, all these metainfo files get collected into
a big AppStream collection file which is then used by GNOME Software
(for example) to present interesting packages to the user in a nice way.

In a modular repository, I think the same thing should happen so that
GNOME Software can present interesting modules to the user in a nice
way.

I think we need to change the collection process in the following ways,
it unfortunately wont just work:

 - Metainfo is in packages, but we need to be installing modules.  Thus,
   the collection data needs to have module names into the AppStream
tag.  I propose to keep AppStream metainfo data in
   packages, and map from package names to module names during
   construction of the collection data.

 - Because of streams and profiles, there can be multiple versions of
   metainfo for a given AppStream component id.  These need to be
   merged, using something like

   https://github.com/ximion/appstream/pull/132[1]

What do you think?

How would you map from a package name to module/stream/profile tuples?

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

Re: No i686 build of grub2?

[Mauricio Tavares]

I think I read here (or in other mailing list) about an interest in
dropping 32bit altogether. But this might be just my imagination.

On Wed, Aug 23, 2017 at 8:27 AM, Bruno Wolff III  wrote:
> Currently grub2 isn't being built for i686 since somewhere between 2.02-8
> and 2.02-10.
> I looked through the change log (but not the git log yet) and didn't see
> anything mentioning this, which I would have expected if it was an
> intentional change.
> So is this a new permanent feature going forward or a temporary oops?
> (I still have one machine I use regularly, that only runs i686 and it will
> probably be a while before I can afford to replace it.)
> ___
> 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: No i686 build of grub2?

[Vascom]

This commit remove add i686 to ExcludeArch
https://src.fedoraproject.org/rpms/grub2/c/ecef1ed7b50ed05b65574c8b8815d7ae66e5a0a9
ExcludeArch: s390 s390x %{arm} %{?ix86}


ср, 23 авг. 2017 г. в 15:35, Bruno Wolff III :

> Currently grub2 isn't being built for i686 since somewhere between
> 2.02-8 and 2.02-10.
> I looked through the change log (but not the git log yet) and didn't see
> anything mentioning this, which I would have expected if it was an
> intentional change.
> So is this a new permanent feature going forward or a temporary oops?
> (I still have one machine I use regularly, that only runs i686 and it
> will probably be a while before I can afford to replace it.)
> ___
> 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: Removal of code signing trust bits from ca-certificates

[Kai Engert]

There hasn't been any negative feedback, neither in Rawhide, nor from updates
testing.

I've just pushed the update to stable F25 and F26.

Kai


On Tue, 2017-07-18 at 22:11 +0200, Kai Engert wrote:
> Until recently, Mozilla maintained three individual trust bits for each root
> CA
> certificate:
> - trust for TLS servers
> - trust for email security
> - trust for code signing
> 
> The next CA update from Mozilla will switch the code signing trust bit
> OFF for all CAs.
> 
> Mozilla will no longer maintain this trust bit.
> 
> See 
> https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/004uvRRnVy
> Y
> for background.
> 
> I'm not aware of anyone using this trust bit. The removal might have no
> effect.
> 
> This update of the CA list is supposed to get published with Firefox 56 on
> September 26.
> 
> In order to allow the Fedora community to test potential effects of this
> change,
> I intend to publish an update to the ca-certificates packages early, and keep
> it
> in updates-testing for a few weeks.
> 
> Tracking bug:
> https://bugzilla.redhat.com/show_bug.cgi?id=1472468
> 
> Thanks
> Kai
> ___
> 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: Complicated problem: kiwi and kiwi-gtk conflict

[Miroslav Suchý]

Dne 23.8.2017 v 11:40 Neal Gompa napsal(a):

However, there's a problem. It seems python-kiwi already exists in
Fedora[4], and it's the kiwi-gtk framework[5].

I'm not sure what to do in this scenario. I've requested from upstream
to rename the module[6], but I don't think they'll go for that,
especially since they actually do have the kiwi name in PyPI.

So what can I do?


Ask hguemar (owner of python-kiwi in fedora) to rename python-kiwi to 
python-kiwi-gtk.

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

No i686 build of grub2?

[Bruno Wolff III]

Currently grub2 isn't being built for i686 since somewhere between 
2.02-8 and 2.02-10.
I looked through the change log (but not the git log yet) and didn't see 
anything mentioning this, which I would have expected if it was an 
intentional change.

So is this a new permanent feature going forward or a temporary oops?
(I still have one machine I use regularly, that only runs i686 and it 
will probably be a while before I can afford to replace it.)

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

Re: autoconf-archive suddenly gone in EPEL 7

[Stephen Gallagher]

On Tue, Aug 22, 2017 at 8:41 AM Benjamin Kircher 
wrote:

>
> > On 22. Aug 2017, at 12:53, Vascom  wrote:
> >
> > As you can see here
> https://src.fedoraproject.org/rpms/autoconf-archive/commits/epel7
> > autoconf-archive removed from EPEL7 because it must be included in main
> CentOS repos.
>
>
> Thanks for the pointer.
>
> Unfortunately this new RHEL package is not yet in current Vagrant images
> (1707.01) nor available in copr making builds that depend on those Autoconf
> macros fail.
>
>
This is one of those unfortunate things that happens when using CentOS;
major releases trail RHEL and sometimes when things make the shift from
EPEL to RHEL proper, CentOS users end up without some packages available
for a while. We're dealing with the same issue with the `http-parser`
package, which not only got moved from EPEL to RHEL, but also downgraded
the NVR in the process (so we can't just leave the EPEL package in the repo
 until CentOS catches up).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: CI projects in Copr

[Fabio Valentini]

Hi,

As the maintainer of the Pantheon DE components and elementary apps, I
have a setup that runs "nightly" builds of 59 of those packages in the
"decathorpe/elementary-nightly" COPR repository for all supported
fedora releases.

This "CI-like" setup helps me catch upstream changes (that warrant
packaging changes) early, and it has even made it possible for me (and
upstream) to find (and fix) errors and / or incompatible changes
early, and not only after a release was tagged upsteram.

The setup I have for triggering and running the builds is a bit
special, as I use a program that I wrote myself (kentauros [1]), which
is triggered by a systemd timer on my machine. The packaging files
(and the program itself) are available on github [2]. I have looked at
tito, but since I don't have access to the upstream repositories, I
needed to find my own solution.

Fabio

[1]: https://github.com/decathorpe/kentauros
[2]: https://github.com/decathorpe/elementary-nightly-rpms

On Wed, Aug 23, 2017 at 1: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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: CI projects in Copr

[Martin Sehnoutka]

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.

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.




signature.asc
Description: OpenPGP digital signature
___
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

[Miroslav Suchý]

Dne 22.8.2017 v 14:53 Michal Novotny napsal(a):

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.



It is there waiting for your karma.

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

Re: Review swap

[Andrea Musuruane]

Hi,

On Wed, Aug 23, 2017 at 12:30 PM, Alexander Ploumistos <
alex.ploumis...@gmail.com> wrote:

> Hello Andrea,
>
> I've taken it, but my ISP is giving me some trouble at the moment,
> they said they'll get things sorted out within the hour.
>
> I don't have a package ready for review yet, but I think I might have
> one by next week.
>

No problem at all.

Let me know when your package will be ready.

Bye,

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

Re: retired packages in rawhide/f27

[Honggang LI]

On Tue, Aug 22, 2017 at 09:29:58AM -0700, Kevin Fenzi wrote:
> On 08/22/2017 02:30 AM, Petr Pisar wrote:
> > On 2017-08-22, Honggang LI  wrote:
> >> hi,
> >>
> >> https://bugzilla.redhat.com/show_bug.cgi?id=1404043#c41
> >> libibcm, libibumad, libibverbs, librdmacm and ibacm had been replaced by
> >> the new rdma-core package. Those five packages are sub-packages of the
> >> new rdma-core package.
> >>
> >> I had retired the f27 and rawhide branches of those five packages in
> >> last week. But the build...@fedoraproject.org keep sending messages to
> >> complain broken dependencies for those five packages.
> >>
> > The "fedgkg retire" tool is/was broken and could not perform a retirement
> > .
> > 
> > Koji reports for ibacm source package:
> > 
> > $ koji list-pkgs --show-blocked --package=ibacm
> > Package Tag Extra Arches Owner  
> > 
> > --- ---  
> > ---
> > [...]
> > ibacm   f27  releng 
> >  [BLOCKED]
> > ibacm   f26-Alphahonli  
> > 
> > ibacm   f26-Beta honli  
> > 
> > ibacm   f28  releng 
> > 
> > 
> > It means the package was not removed from Rawhide (f28) repositories.
> > 
> > If rerunning "fedpkg retire" does not help, you should file a ticket to
> >  or
> > .
> 
> Yeah, the retirement here seems to have only happened in f27.
> 
> I suspect this was right around branching time when you did this and
> something wasn't happy.
> 
> In any case, due to the rdma-core not building on armv7, blocking these
> packages currently breaks composes. (Thats one reason why we have not
> had a branched compose in a while).
> 
> So, I would appreciate it if you could leave f28/rawhide for now (since
> we do get composes there) until we get lorax set to handle things.

I'm still working on to get a ARM32 system or virtual machine. The hold
day was wasted because of different issues of software or hardware.

I will try my best to check the dep chain issue of ARM32. I send this email to
you to avoid spam the mailing list, just to let you know I'm working on
this.

I will reply to the mailing list until I get a working ARM32 system and
checked the dep chain issue.

thanks
> 
> 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

CI projects in Copr

[Miroslav Suchý]

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

Re: Review swap

[Alexander Ploumistos]

Hello Andrea,

I've taken it, but my ISP is giving me some trouble at the moment,
they said they'll get things sorted out within the hour.

I don't have a package ready for review yet, but I think I might have
one by next week.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Review swap

[Andrea Musuruane]

Hi!
I'm looking for a reviewer for

osmctools - Tools to manipulate OpenStreetMap files:
https://bugzilla.redhat.com/show_bug.cgi?id=1464777

Maybe some other OSM mapper is interested?

I'm happy to exchange reviews.

Thanks in advance.

Bye,

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

Complicated problem: kiwi and kiwi-gtk conflict

[Neal Gompa]

Hey all,

So I submitted a review request on Sunday for python-kiwi[1], which is
the KIWI appliance image builder tool from SUSE[2] and is registered
in PyPI as kiwi[3].

However, there's a problem. It seems python-kiwi already exists in
Fedora[4], and it's the kiwi-gtk framework[5].

I'm not sure what to do in this scenario. I've requested from upstream
to rename the module[6], but I don't think they'll go for that,
especially since they actually do have the kiwi name in PyPI.

So what can I do?

[1]: https://bugzilla.redhat.com/show_bug.cgi?id=1483339
[2]: https://github.com/SUSE/kiwi
[3]: https://pypi.org/project/kiwi/
[4]: https://src.fedoraproject.org/rpms/python-kiwi
[5]: https://pypi.org/project/kiwi-gtk/
[6]: https://github.com/SUSE/kiwi/issues/471

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

Re: [DONE] Mass package change (python2- binary package renaming)

[Kalev Lember]

On 08/23/2017 02:00 AM, Kevin Fenzi wrote:
> Also, I'd like to very much thank you for doing this work. :)
> It's great to get done, it's great to do it quickly and I know it's a
> lot of hard work to script and build things.

Yes, thank you for doing this, Zbyszek!

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

Re: src.fedoraproject.org, forking projects, PRs

[Pierre-Yves Chibon]

On Wed, Aug 23, 2017 at 09:44:56AM +0200, Dan Horák wrote:
> On Wed, 23 Aug 2017 07:34:22 -
> "Wolfgang Stoeggl"  wrote:
> 
> > Hello,
> > is forking projects, PRs etc. already supposed to work at
> > src.fedoraproject.org? So far, I am getting the following:
> > 
> > # Source GIT URL: SSH
> > git clone ssh://pkgs.fedoraproject.org/forks/c72578/rpms/cacti.git
> > Permission denied (publickey).
> > # Remark: the ~/.ssh/id_rsa key is present here and working (e.g. for
> > # fedpkg)
> 
> I had to change the URL to contain my username when I forked FF
> ssh://shar...@pkgs.fedoraproject.org/forks/sharkcz/rpms/firefox.git
> 
> I guess that's a bug how pagure provides the cloning URL

Our usage of gitolite in dist-git is quite convoluted and pagure (the
application) was written with the traditional deployment of gitolite in mind.

There is a ticket in pagure (the app) to make it support the specificities of
the deployment in dist-git:
https://pagure.io/pagure/issue/2524


Let's see if I can get to it quickly :)

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

Re: introducing fed-install: easy way to install packages from koji and other releases

[Tomas Tomecek]

On Sun, Aug 20, 2017 at 10:59 PM, Kevin Fenzi  wrote:

>
> First, one thing that would be very handy (but could perhaps just be a
> dnf plugin) is to install from koji, but use signed packages (if
> available). I'm not sure how hard it would be to implement in your tool,
> but you might take a look if you are interested.
>

What would be the place to pick the signed packages from?

I think this is a great suggestion​. The reason it's implemented like this
is because I had no idea where to get those signed packages.



> Secondly, I think this could indeed be handy for folks running rawhide
> or branched, but I worry about people on stable releases mistakenly
> using it and upgrading a chunk of their install to rawhide when they
> didn't realize it would do that. Not sure how to prevent that though,
> perhaps a warning in some cases?
>

I like this suggestion. I opened an upstream issue for that:

https://github.com/TomasTomecek/fed-install/issues/3


> Anyhow, will poke around with the tool and let you know any further
> thoughts. Thanks for sharing!
>
> kevin
>

​Thanks Kevin!​


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

[modularity] Modularizing the world fast and iteratively

[Adam Samalik]

Starting with a summary: ​Let's 1) use something like dependency-report
scripts [1] to get coordinated, and 2) make the initial builds against
bootstrap so we get a working thing fast and can iterate.


I've realized that developing the initial set of modules for F27 could be a
bit tricky in the beginning as some things might require many basic
dependencies on top of Platform to run and build. These dependencies, like
autotools or dynamic languages for example, need to get modularized first.

In F26 Boltron we had a 'shared-userspace' and 'shared-build-dependencies'
modules that kind of randomly included many of the shared dependencies of
other modules. I don't think that's necessarily terrible (although I'm sure
contyk would argue it is!), but it's not ideal. We should make modules that
represent a thing, like autotools, python2, python3, ruby, gtk2, gtk3, git,
etc. But making all of these modules on a greenfield without a solid base
could be tricky. How do we help people to know what they should include,
and what's going to be somewhere else?

For this, I have written a set of scripts, and already named them badly
'dependency-report' [1]. We have tested it with FreeIPA maintainers to
generate a dependency report [2] for them, and we have already identified
many modules that FreeIPA need as dependencies. I think we could use this
to help us with the initial design.

This brings me to my second thought... to build what we want, we need to
modularize a lot of other stuff. And when we are ready with the initial
design - that means we have identified all the modules we want to have and
all their dependencies, we need to build them. But, for example, a pretty
commonly needed thing like autotools [3] has pretty crazy build
dependencies [4] including Java, gtk2, gtk3, erlang, X11, python2, python3,
etc. And many of these need autotools, of course. We need to do
bootstraping.

So instead of trying to make everything perfect from the begining, we could
build everything we need against the Bootstrap module - a module that is
used as a buildroot for Host and Platform and contains mostly everything we
need. To compare, there is a report without using bootstrap [5] and with
using bootstrap [6]. This way we'll have a pretty decent set of module very
soon.

The next step would be lookin at the build dependencies of these initial
modules, building them against bootstrap, and rebuilding the initial
modules against these new ones. And then do it for the new ones as well,
until we have everything in place.

Also, with this top-down approach, we'll be flexible with the frequent
changes of the Platform module as it's getting stabilized which also makes
the design of the low-level modules nearly impossible right now.

With this approach, we:
1) get coordinated and make modules without conflicts
2) have a working thing very soon
3) can iterate on expanding the base set over time


If you'd like to participate, please feel free to propose your module on
the F27 content plan [7], I'll make you a repository under the
modularity-modules space [8] which serves as an input to the scripts, and
include your module in there.

Cheers!
Adam


[1] https://github.com/fedora-modularity/dependency-report
[2]
https://github.com/fedora-modularity/dependency-report/tree/master/modules/freeipa
[3]
https://github.com/fedora-modularity/dependency-report/tree/original-plan/modules/autotools
[4]
https://github.com/fedora-modularity/dependency-report/blob/original-plan/modules/autotools/all/buildtime-binary-packages-short.txt
[5]
https://github.com/fedora-modularity/dependency-report/tree/original-plan/global_reports
[6]
https://github.com/fedora-modularity/dependency-report/tree/bootstrap/global_reports
[7] https://github.com/fedora-modularity/f27-content-tracking
[8] https://github.com/modularity-modules

-- 

Adam Šamalík
---
Software Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: src.fedoraproject.org, forking projects, PRs

[Wolfgang Stoeggl]

Thanks for the hint!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: src.fedoraproject.org, forking projects, PRs

[Dan Horák]

On Wed, 23 Aug 2017 07:34:22 -
"Wolfgang Stoeggl"  wrote:

> Hello,
> is forking projects, PRs etc. already supposed to work at
> src.fedoraproject.org? So far, I am getting the following:
> 
> # Source GIT URL: SSH
> git clone ssh://pkgs.fedoraproject.org/forks/c72578/rpms/cacti.git
> Permission denied (publickey).
> # Remark: the ~/.ssh/id_rsa key is present here and working (e.g. for
> # fedpkg)

I had to change the URL to contain my username when I forked FF
ssh://shar...@pkgs.fedoraproject.org/forks/sharkcz/rpms/firefox.git

I guess that's a bug how pagure provides the cloning URL


Dan


> 
> # Source GIT URL: GIT
> git clone https://src.fedoraproject.org/forks/c72578/rpms/cacti.git
> cd cacti
> git push
> fatal: unable to access
> 'https://src.fedoraproject.org/forks/c72578/rpms/cacti.git/': The
> requested URL returned error: 403
> 
> So far, there is documentation on forking projects on pagure.io, what
> about src.fedoraproject.org? e.g.:
> https://fedoraproject.org/wiki/How_to_fix_bugs_on_the_Fedora_Project_website
> https://docs.pagure.org/releng/contributing.html
> 
> Thanks
> Wolfgang
> ___
> 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

src.fedoraproject.org, forking projects, PRs

[Wolfgang Stoeggl]

Hello,
is forking projects, PRs etc. already supposed to work at src.fedoraproject.org?
So far, I am getting the following:

# Source GIT URL: SSH
git clone ssh://pkgs.fedoraproject.org/forks/c72578/rpms/cacti.git
Permission denied (publickey).
# Remark: the ~/.ssh/id_rsa key is present here and working (e.g. for fedpkg)

# Source GIT URL: GIT
git clone https://src.fedoraproject.org/forks/c72578/rpms/cacti.git
cd cacti
git push
fatal: unable to access 
'https://src.fedoraproject.org/forks/c72578/rpms/cacti.git/': The requested URL 
returned error: 403

So far, there is documentation on forking projects on pagure.io, what about 
src.fedoraproject.org?
e.g.:
https://fedoraproject.org/wiki/How_to_fix_bugs_on_the_Fedora_Project_website
https://docs.pagure.org/releng/contributing.html

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