Re: HEADS UP: libwebp-0.6.0 soname bumps

[Kalev Lember]

On 02/01/2017 06:59 PM, Sandro Mani wrote:
> Hi
> 
> I'm about to fire off the libwebp and mingw-libwebp 0.6.0 updates, which
> include soname bumps.
> 
> I'm rebuilding all of the dependent packages:

Hi Sandro,

Thanks for working on this! The number of packages affected by the
soname bump is quite big though and I think it needs a compat package.
We probably wouldn't have to keep it around for a long time, but maybe
it should be there during the F26 lifetime and get retired in F27.

This is a bit pressing right now because webkitgtk4 is currently failing
to rebuild and that is causing broken deps for Workstation and leading
to the QA nightly tests not working and so on.

I also imagine there are a bunch of third party packages that are still
linking with old libwebp soname and would benefit if we kept the ABI
compatibility as well.

Would you have time to review a compat package and help maintain it if I
put one together?

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

Re: packaging work is becoming increasingly cumbersome

[Julian Sikorski]

W dniu 01.02.2017 o 09:12, Lubomír Sedlář pisze:
> Kevin Fenzi píše v Út 31. 01. 2017 v 16:19 -0700:
>> On Tue, 31 Jan 2017 23:26:29 +0100
>> Julian Sikorski  wrote:
>>
>>> - chain-building has been broken for a month [2] so now requesting
>>> each build in the chain separately is required
>>
>> I just did a ping on that issue. Hopefully we can get a new release
>> out with the fix soon. I know rdieter made a local patch he's been
>> using fine, so this really should not be that hard to push out. 
> 
> We've had the patch for some time now, but due to churn around DevConf
> did not manage to get them out yet. I just made the builds and
> submitted updates. Please try them out and give feedback.
> 
> https://bodhi.fedoraproject.org/updates/FEDORA-2017-a11eb3284c
> https://bodhi.fedoraproject.org/updates/FEDORA-2017-6808c6d2dc
> https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-209d47f2aa
> https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-b65a190953
> 
> Make sure to install both pyrpkg and fedpkg from the update, otherwise
> the fix will not work (but nothing else should break).
> 

I have already released the gnumeric/goffice update so I have no test
case at the moment unfortunately. But thank you for releasing, will
definitely test and report back once I do have one.

>>> - fedpkg now needs authentication via kerberos instead of ssh key
>>> [3],
>>> which means that I now have to run kinit before starting a
>>> packaging
>>> session, in addition to firing up keepass and entering the password
>>
>> Yeah. This will hopefully be helped by the upcoming kerberos cache
>> change. 
> 
> Or you could set up Gnome Online Accounts and it will get the ticket
> for you automatically.
> 
I did not know that was possible, thank you!

Best regards,
Julian

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

Re: HEADS UP: libwebp-0.6.0 soname bumps

[Björn 'besser82' Esser]

Am 01.02.2017 um 18:59 schrieb Sandro Mani:

Hi

I'm about to fire off the libwebp and mingw-libwebp 0.6.0 updates, 
which include soname bumps.


I'm rebuilding all of the dependent packages:

darktable-2.2.2-1.fc26.src.rpm
efl-1.18.4-2.fc26.src.rpm
freeimage-3.17.0-8.fc26.src.rpm
gd-2.2.4-1.fc26.src.rpm
gdal-2.1.2-6.fc26.src.rpm
gegl03-0.3.10-1.fc26.src.rpm
gnuplot-5.0.5-1.fc26.src.rpm
grads-2.0.2-20.fc26.src.rpm
GraphicsMagick-1.3.25-2.fc26.src.rpm
gstreamer1-plugins-bad-free-1.11.1-1.fc26.src.rpm
gthumb-3.4.4.1-2.fc26.src.rpm
guacamole-server-0.9.9-2.fc26.src.rpm
ImageMagick-6.9.3.0-3.fc25.src.rpm
kde-runtime-16.12.1-1.fc26.src.rpm
leptonica-1.74.1-1.fc26.src.rpm
librasterlite2-1.0.0-3.rc0.fc24.4.src.rpm
mapnik-3.0.12-4.fc26.src.rpm
mscgen-0.20-17.fc25.src.rpm
nut-2.7.4-5.fc26.src.rpm
opencv-3.1.0-12.fc26.src.rpm
OpenImageIO-1.7.10-1.fc26.src.rpm
pcb-0.20140316-10.fc25.src.rpm
perl-GD-2.56-9.fc25.src.rpm
purple-telegram-1.3.0-1.fc26.src.rpm
python-mapnik-0.1-12.20160909git541fd96.fc26.src.rpm
python-pillow-4.0.0-1.fc26.src.rpm
python-webm-0.2.2-11.fc25.src.rpm
qt5-qtimageformats-5.7.1-2.6.fc26.src.rpm
qt5-qtimageformats-5.7.1-2.fc26.src.rpm
qt5-qtwebengine-5.7.1-6.fc26.src.rpm
qt5-qtwebengine-freeworld-5.7.1-5.fc26.src.rpm
qt5-qtwebkit-5.7.1-3.fc26.src.rpm
qtwebkit-2.3.4-12.fc26.src.rpm
SDL2_image-2.0.1-3.fc26.src.rpm
vdr-burn-0.3.0-3.fc26.src.rpm
vips-8.4.4-2.fc26.src.rpm
webkitgtk-2.4.11-3.fc25.src.rpm
webkitgtk3-2.4.11-3.fc25.src.rpm
webkitgtk4-2.15.3-1.fc26.src.rpm
weston-1.12.0-1.fc26.src.rpm
WindowMaker-0.95.7-3.fc24.src.rpm

mingw-freeimage-3.17.0-5.fc26.src.rpm
mingw-gdal-2.1.2-1.fc26.src.rpm
mingw-leptonica-1.74.1-1.fc26.src.rpm
mingw-qt5-qtimageformats-5.6.0-2.fc26.src.rpm
mingw-qt5-qtwebkit-5.5.1-2.fc24.src.rpm
mingw-qtwebkit-2.3.4-1.fc26.src.rpm
mingw-SDL2_image-2.0.1-1.fc26.src.rpm
mingw-webkitgtk-2.4.11-2.fc26.src.rpm
mingw-webkitgtk3-2.4.11-2.fc26.src.rpm


Sandro


Hi Sandro,

could you please tell me, when gnuplot has been rebuilt successfully?

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

Re: F26 System Wide Change: Python Classroom Lab

[William Moreno]

 Awesome!

Just a small note here, I'll add a desktop file for idle3 soon, there is
already a bugzilla [0] for that.

[0] https://bugzilla.redhat.com/show_bug.cgi?id=1392049
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: Python Classroom Lab

[Charalampos Stratakis]

Just a small note here, I'll add a desktop file for idle3 soon, there is 
already a bugzilla [0] for that.

[0] https://bugzilla.redhat.com/show_bug.cgi?id=1392049

Regards,

Charalampos Stratakis
Associate Software Engineer
Python Maintenance Team, Red Hat


- Original Message -
From: "William Moreno" 
To: "Development discussions related to Fedora" 
Sent: Wednesday, February 1, 2017 11:43:24 PM
Subject: Re: F26 System Wide Change: Python Classroom Lab




... 

The Workstation based lab will also contain: 
* Basic GNOME 
* Terminal emulator 
* Text editor 
* PDF reader 
* Web browser 
* Image viewer 
* ...and possibly other utilities 

In Workstation you can find the idle3 executable in /usr/bin but users will not 
note it because there is not a grafical launcher in the desktop, my U$ 0.02 

Make idle3 a subpackage and make it available with a proper .desktop file and a 
.appdata.xml file 

Also there are 2 python IDES in the repo than are python powered : eric and 
ninja-ide than can be included in the spin, also we have pydev but this is java 
powered 

___
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: F26 System Wide Change: Python Classroom Lab

[William Moreno]

...

The Workstation based lab will also contain:
* Basic GNOME
* Terminal emulator
* Text editor
* PDF reader
* Web browser
* Image viewer
* ...and possibly other utilities



In Workstation you can find the idle3 executable in /usr/bin but users will
not note it because there is not a grafical launcher in the desktop, my U$
0.02

Make idle3 a subpackage and make it available with a proper .desktop file
and a .appdata.xml file

Also there are 2 python IDES in the repo than are python powered : eric and
ninja-ide than can be included in the spin, also we have pydev but this is
java powered
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: koji failed to build srpm from scm

[Jonny Heggheim]

Tom Hughes:
> Yes there is:
> 
> https://kojipkgs.fedoraproject.org/work/tasks/5224/17545224/build.log
> 
> Looks like the source is missing - did you upload it to the lookaside
> cache?

Thanks, the sources file did not have the source tarball entry.

Jonny



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: koji failed to build srpm from scm

[Tom Hughes]

On 01/02/17 21:20, Jonny Heggheim wrote:


I am getting this error:

BuildError: error building srpm, mock exited with status 1;
see build.log for more information


But there is no build.log :\


Yes there is:

https://kojipkgs.fedoraproject.org/work/tasks/5224/17545224/build.log

Looks like the source is missing - did you upload it to the lookaside cache?

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

koji failed to build srpm from scm

[Jonny Heggheim]

Hi,

I am getting this error:
> BuildError: error building srpm, mock exited with status 1;
> see build.log for more information

But there is no build.log :\

Both fedpkg mockbuild and fedpkg srpm work on local machine. Fails on
koji for both f25 and rawhide. Is the problem on my machine or is there
something wrong with our infrastructure?

Koji build: https://koji.fedoraproject.org/koji/taskinfo?taskID=17545223


Sincerely Jonny Heggheim



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: F26 System Wide Change: Python Classroom Lab

[Matthew Miller]

On Wed, Feb 01, 2017 at 10:40:27AM -0500, Stephen Gallagher wrote:
> Sure it can; you just create a metapackage that Requires/Recommends:
> all of the members of the comps group and add AppData XML and a logo
> to that metapackage.

It would be nice to have a feature like this in Software where we could
make this a top-level "Fedora software sets" (or, I guess, "Fedora
Labs") section. I'll talk to the developers about it.


-- 
Matthew Miller

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

Re: F26 System Wide Change: Python Classroom Lab

[Amit Saha]

On Thu, 2 Feb 2017 at 5:20 am, Brian (bex) Exelbierd  wrote:

>
>
> > On Jan 31, 2017, at 1:16 PM, Miro Hrončok  wrote:
> >
> >> On 31.1.2017 09:13, Amit Saha wrote:
> >> Hello Jan,
> >>
> >> The Fedora Scientific spin already includes most  of the Python 3
> >> packages you are looking at. Is it worth looking at that instead of a
> >> new spin? I am happy to change it to use GNOME instead of KDE.
> >
> > Hi. It's not about GNOME/KDE, it's about main purpose of such lab and
> also marketing. Compare:
> >
> > > Use Fedora for teaching Python, it has a Python Clasroom Lab available
> just for that!
> >
> > With:
> >
> > > Use Fedora for teaching Python, it has a Scientific Spin that happens
> to have all the Python 3 tools needed!
>
> Phrased this way I agree with you. However, I think your wording is pretty
> harsh. I'm on a plane right now so I don't have the Scientific Spin
> marketing message in hand, but I think you could say:
>
> Teaching or learning python, the Fedora Scientific Spin is a great way to
> easily have all the tools you need. It also supports additional educational
> options with the included science components.
>
> Before pushing on this I'd like to see the Scientific Spin's build size.



As the maintainer of this spin, I would be to discuss any changes to be
suitable for meeting the needs of both target audiences.



>
> Regards,
>
> bex
>
>
>
> >
> >>
> >>
> >>
> >> Have you though
> >> On Tue, 31 Jan 2017 at 6:31 pm, Jan Kurik  >> > wrote:
> >>
> >>= System Wide Change: Python Classroom Lab =
> >>https://fedoraproject.org/wiki/Changes/PythonClassroomLab
> >>
> >>Change owner(s):
> >>* Miro Hrončok 
> >>* SIGs/Python  >>>
> >>
> >>
> >>A new Python Classroom Lab will be created in 3 variants: Workstation
> >>based, Docker based and Vagrant based. It's an important step for our
> >>Fedora Loves Python initiative. The main audience are Python teachers
> >>and workshop instructors.
> >>
> >>
> >>== Detailed Description ==
> >>A new comps packages group with Python development tools will be
> >>created and a new Lab (or Spin) for teaching Python or Python related
> >>topics will be available from labs.fedoraproject.org
> >> as well as from
> >>the Docker Hub and Vagrant Atlas.
> >>
> >>A work in progress for the lab is available on GitHub.
> >>
> >>The Lab will contain:
> >>* Python 3.6 including the python3-devel package
> >>* Python 2.7 including the python2-devel package
> >>* PyPy 3
> >>* tox
> >>* virtualenv
> >>* IPython console for both Python 2 and 3
> >>* Jupyter Notebook with Python 2 and 3 kernels (if this gets into
> >>Fedora in time)
> >>* offline documentation for Python 2 and 3
> >>* basic toolchain for building C and C++ extensions and valgrind
> >>* git
> >>* nano, vim, ssh client, curl, wget
> >>* devel packages for commonly used dependencies of packages on the
> >>Python Package Index
> >>* * libxml2-devel
> >>* * libyaml-devel
> >>...
> >>
> >>The Workstation based lab will also contain:
> >>* Basic GNOME
> >>* Terminal emulator
> >>* Text editor
> >>* PDF reader
> >>* Web browser
> >>* Image viewer
> >>* ...and possibly other utilities
> >>
> >>But it will not include multimedia and virtualization support, office
> >>suite, e-mail client.
> >>
> >>
> >>== Scope ==
> >>Proposal owners:
> >>* create the comps group
> >>* create kickstarts for live and vagrant variants
> >>* create a layer for docker
> >>
> >>Other developers:
> >>* Design team: Create an image for labs.fedoraproject.org
> >>
> >>* Websites team: Add the new Lab to labs.fedoraproject.org
> >>
> >>
> >>Release engineering:
> >>List of deliverables:
> >>*
> >>
> Labs/i386/iso/Fedora-Python-Classroom-Live-i386-_RELEASE_MILESTONE_.iso
> >>*
> >>
> Labs/x86_64/iso/Fedora-Python-Classroom-Live-x86_64-_RELEASE_MILESTONE_.iso
> >>*
> >>
> Labs/armhfp/images/Fedora-Python-Classroom-armhfp-_RELEASE_MILESTONE_-sda.raw.xz
> >>*
> >>
> Labs/i386/images/Fedora-Python-Classroom-Vagrant-_RELEASE_MILESTONE_.i386.vagrant-libvirt.box
> >>*
> >>
> Labs/i386/images/Fedora-Python-Classroom-Vagrant-_RELEASE_MILESTONE_.i386.vagrant-virtualbox.box
> >>*
> >>
> Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-_RELEASE_MILESTONE_.x86_64.vagrant-libvirt.box
> >>*
> >>
> Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-_RELEASE_MILESTONE_.x86_64.vagrant-virtualbox.box
> >>* docker images via Fedora Docker Layered image build service
> >>
> >>Policies and guidelines: nothing
> >>
> >>Trademark approval: waiting
> >>--
> >>Jan Kuřík
> >>Platform & Fedora Program Manager
> >>Red Hat Czech s.r

Re: F26 Self Contained Change: Anaconda LVM RAID

[Chris Murphy]

Actually, I've got a concern about this feature.

I'm not sure what gnome-shell depends on for monitoring mdadm arrays,
but I know it will put up a notification if an mdadm member becomes
faulty; because I've seen this notification. Maybe it's getting this
information from udisksd? In any case, I'm wondering whether the user
will still be notified of device failures in gnome-shell with this
change?

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

Re: F26 Self Contained Change: Anaconda LVM RAID

[Chris Murphy]

On Wed, Feb 1, 2017 at 4:55 AM, David Woodhouse  wrote:

>
> Please ensure upgrades of systems using MD RAID are properly tested.

Please help test upgrades if there's a layout you want to work. The
only way anything gets tested is if someone does the test.


> My server at home broke on upgrading to Fedora 22 (#1201962), and also
> on upgrading to Fedora 20 before that (IIRC).

That's a while ago, the system upgrade method is different now. At
least on workstation it's using systemd offline update to do the major
version upgrade, same as minor updates. So if it's able to do minor
updates without breaking, it should be able to do the major one
successfully. Whether there may be a bug that prevents a successfully
upgraded system from booting - well that's what testing is for.

>So let's please ensure that we have proper
> test coverage for existing systems.

Please describe your proposal for ensuring proper test coverage, in
particular if you personally aren't able to test what is by definition
a custom layout?


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

Dependency rebuild order

[Sandro Mani]

Hi

Wondering if someone has some neat script which outputs the rebuild 
order of a set of packages, say after a library these depend on bumped 
its soname.


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

Orphaning xlogin

[Raphael Groner]

Hi,

because of lack of free time to actively maintan all of my packages with trying 
to give the same chances to all of them, I decided to orphan xlogin.
Also, I don't use xlogin any more due to some issues with SELinux.

Please feel free to pick the package up. I'll click the orphan button just 
after sent this e-mail.

rpms/xlogin -- Automatic X login service for systemd ( master f25 f24 epel7 ) 

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

Re: packaging work is becoming increasingly cumbersome

[Mikolaj Izdebski]

On 02/01/2017 02:56 AM, Jonathan Wakely wrote:
>> - fedpkg now needs authentication via kerberos instead of ssh key [3],
>> which means that I now have to run kinit before starting a packaging
>> session, in addition to firing up keepass and entering the password
> 
> You can request a renewable ticket that can be renewed for up to seven
> days, and have a cron job automatically renew it every 12 hours to
> stop it expiring. That reduces the inconvenience.

Or you can generate keytab with ktutil and then you can get tickets with
kinit -k, without typing password, possibly from cron job.

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

Re: packaging work is becoming increasingly cumbersome

[Kevin Fenzi]

On Wed, 1 Feb 2017 10:05:50 -0800
Andrew Lutomirski  wrote:

> On Tue, Jan 31, 2017 at 2:26 PM, Julian Sikorski 
> wrote:
> > While I am sure these changes are done with an aim of improving
> > things in the long run, the churn caused by them is really starting
> > to take a toll on my motivation. Could something be done to
> > mitigate the inconveniences caused by the infrastructure upgrades?
> >  
> 
> From memory, there seem to have been a number of server-side changes
> in Fedora's infrastructure that are deployed before the relevant
> updates become stable.  Would it make sense to try to avoid making
> breaking changes to the infrastructure until the mandatory updates
> have been in -updates long enough to mirror out all the way?

In some cases that is definitely an option. 

For some of the things at the flag day it wasn't because if the package
was stable before we changed the server side it may have stopped
working at all for people. 

In any case I don't think we have any more flag days planned (and
hopefully we can avoid them).

kevin


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

Re: F26 System Wide Change: Python Classroom Lab

[Brian (bex) Exelbierd]

> On Jan 31, 2017, at 1:16 PM, Miro Hrončok  wrote:
> 
>> On 31.1.2017 09:13, Amit Saha wrote:
>> Hello Jan,
>> 
>> The Fedora Scientific spin already includes most  of the Python 3
>> packages you are looking at. Is it worth looking at that instead of a
>> new spin? I am happy to change it to use GNOME instead of KDE.
> 
> Hi. It's not about GNOME/KDE, it's about main purpose of such lab and also 
> marketing. Compare:
> 
> > Use Fedora for teaching Python, it has a Python Clasroom Lab available just 
> > for that!
> 
> With:
> 
> > Use Fedora for teaching Python, it has a Scientific Spin that happens to 
> > have all the Python 3 tools needed!

Phrased this way I agree with you. However, I think your wording is pretty 
harsh. I'm on a plane right now so I don't have the Scientific Spin marketing 
message in hand, but I think you could say:

Teaching or learning python, the Fedora Scientific Spin is a great way to 
easily have all the tools you need. It also supports additional educational 
options with the included science components. 

Before pushing on this I'd like to see the Scientific Spin's build size.  

Regards,

bex



> 
>> 
>> 
>> 
>> Have you though
>> On Tue, 31 Jan 2017 at 6:31 pm, Jan Kurik > > wrote:
>> 
>>= System Wide Change: Python Classroom Lab =
>>https://fedoraproject.org/wiki/Changes/PythonClassroomLab
>> 
>>Change owner(s):
>>* Miro Hrončok 
>>* SIGs/Python >>
>> 
>> 
>>A new Python Classroom Lab will be created in 3 variants: Workstation
>>based, Docker based and Vagrant based. It's an important step for our
>>Fedora Loves Python initiative. The main audience are Python teachers
>>and workshop instructors.
>> 
>> 
>>== Detailed Description ==
>>A new comps packages group with Python development tools will be
>>created and a new Lab (or Spin) for teaching Python or Python related
>>topics will be available from labs.fedoraproject.org
>> as well as from
>>the Docker Hub and Vagrant Atlas.
>> 
>>A work in progress for the lab is available on GitHub.
>> 
>>The Lab will contain:
>>* Python 3.6 including the python3-devel package
>>* Python 2.7 including the python2-devel package
>>* PyPy 3
>>* tox
>>* virtualenv
>>* IPython console for both Python 2 and 3
>>* Jupyter Notebook with Python 2 and 3 kernels (if this gets into
>>Fedora in time)
>>* offline documentation for Python 2 and 3
>>* basic toolchain for building C and C++ extensions and valgrind
>>* git
>>* nano, vim, ssh client, curl, wget
>>* devel packages for commonly used dependencies of packages on the
>>Python Package Index
>>* * libxml2-devel
>>* * libyaml-devel
>>...
>> 
>>The Workstation based lab will also contain:
>>* Basic GNOME
>>* Terminal emulator
>>* Text editor
>>* PDF reader
>>* Web browser
>>* Image viewer
>>* ...and possibly other utilities
>> 
>>But it will not include multimedia and virtualization support, office
>>suite, e-mail client.
>> 
>> 
>>== Scope ==
>>Proposal owners:
>>* create the comps group
>>* create kickstarts for live and vagrant variants
>>* create a layer for docker
>> 
>>Other developers:
>>* Design team: Create an image for labs.fedoraproject.org
>>
>>* Websites team: Add the new Lab to labs.fedoraproject.org
>>
>> 
>>Release engineering:
>>List of deliverables:
>>*
>>Labs/i386/iso/Fedora-Python-Classroom-Live-i386-_RELEASE_MILESTONE_.iso
>>*
>>
>> Labs/x86_64/iso/Fedora-Python-Classroom-Live-x86_64-_RELEASE_MILESTONE_.iso
>>*
>>
>> Labs/armhfp/images/Fedora-Python-Classroom-armhfp-_RELEASE_MILESTONE_-sda.raw.xz
>>*
>>
>> Labs/i386/images/Fedora-Python-Classroom-Vagrant-_RELEASE_MILESTONE_.i386.vagrant-libvirt.box
>>*
>>
>> Labs/i386/images/Fedora-Python-Classroom-Vagrant-_RELEASE_MILESTONE_.i386.vagrant-virtualbox.box
>>*
>>
>> Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-_RELEASE_MILESTONE_.x86_64.vagrant-libvirt.box
>>*
>>
>> Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-_RELEASE_MILESTONE_.x86_64.vagrant-virtualbox.box
>>* docker images via Fedora Docker Layered image build service
>> 
>>Policies and guidelines: nothing
>> 
>>Trademark approval: waiting
>>--
>>Jan Kuřík
>>Platform & Fedora Program Manager
>>Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
>>___
>>devel mailing list -- devel@lists.fedoraproject.org
>>
>>To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>>
>> 
>> --
>> http://echorand.me
>> 
>> 
>> _

Re: packaging work is becoming increasingly cumbersome

[Andrew Lutomirski]

On Tue, Jan 31, 2017 at 2:26 PM, Julian Sikorski  wrote:
> While I am sure these changes are done with an aim of improving things
> in the long run, the churn caused by them is really starting to take a
> toll on my motivation. Could something be done to mitigate the
> inconveniences caused by the infrastructure upgrades?
>

From memory, there seem to have been a number of server-side changes
in Fedora's infrastructure that are deployed before the relevant
updates become stable.  Would it make sense to try to avoid making
breaking changes to the infrastructure until the mandatory updates
have been in -updates long enough to mirror out all the way?

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

HEADS UP: libwebp-0.6.0 soname bumps

[Sandro Mani]

Hi

I'm about to fire off the libwebp and mingw-libwebp 0.6.0 updates, which 
include soname bumps.


I'm rebuilding all of the dependent packages:

darktable-2.2.2-1.fc26.src.rpm
efl-1.18.4-2.fc26.src.rpm
freeimage-3.17.0-8.fc26.src.rpm
gd-2.2.4-1.fc26.src.rpm
gdal-2.1.2-6.fc26.src.rpm
gegl03-0.3.10-1.fc26.src.rpm
gnuplot-5.0.5-1.fc26.src.rpm
grads-2.0.2-20.fc26.src.rpm
GraphicsMagick-1.3.25-2.fc26.src.rpm
gstreamer1-plugins-bad-free-1.11.1-1.fc26.src.rpm
gthumb-3.4.4.1-2.fc26.src.rpm
guacamole-server-0.9.9-2.fc26.src.rpm
ImageMagick-6.9.3.0-3.fc25.src.rpm
kde-runtime-16.12.1-1.fc26.src.rpm
leptonica-1.74.1-1.fc26.src.rpm
librasterlite2-1.0.0-3.rc0.fc24.4.src.rpm
mapnik-3.0.12-4.fc26.src.rpm
mscgen-0.20-17.fc25.src.rpm
nut-2.7.4-5.fc26.src.rpm
opencv-3.1.0-12.fc26.src.rpm
OpenImageIO-1.7.10-1.fc26.src.rpm
pcb-0.20140316-10.fc25.src.rpm
perl-GD-2.56-9.fc25.src.rpm
purple-telegram-1.3.0-1.fc26.src.rpm
python-mapnik-0.1-12.20160909git541fd96.fc26.src.rpm
python-pillow-4.0.0-1.fc26.src.rpm
python-webm-0.2.2-11.fc25.src.rpm
qt5-qtimageformats-5.7.1-2.6.fc26.src.rpm
qt5-qtimageformats-5.7.1-2.fc26.src.rpm
qt5-qtwebengine-5.7.1-6.fc26.src.rpm
qt5-qtwebengine-freeworld-5.7.1-5.fc26.src.rpm
qt5-qtwebkit-5.7.1-3.fc26.src.rpm
qtwebkit-2.3.4-12.fc26.src.rpm
SDL2_image-2.0.1-3.fc26.src.rpm
vdr-burn-0.3.0-3.fc26.src.rpm
vips-8.4.4-2.fc26.src.rpm
webkitgtk-2.4.11-3.fc25.src.rpm
webkitgtk3-2.4.11-3.fc25.src.rpm
webkitgtk4-2.15.3-1.fc26.src.rpm
weston-1.12.0-1.fc26.src.rpm
WindowMaker-0.95.7-3.fc24.src.rpm

mingw-freeimage-3.17.0-5.fc26.src.rpm
mingw-gdal-2.1.2-1.fc26.src.rpm
mingw-leptonica-1.74.1-1.fc26.src.rpm
mingw-qt5-qtimageformats-5.6.0-2.fc26.src.rpm
mingw-qt5-qtwebkit-5.5.1-2.fc24.src.rpm
mingw-qtwebkit-2.3.4-1.fc26.src.rpm
mingw-SDL2_image-2.0.1-1.fc26.src.rpm
mingw-webkitgtk-2.4.11-2.fc26.src.rpm
mingw-webkitgtk3-2.4.11-2.fc26.src.rpm


Sandro


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

Re: Boost 1.63 rebuilds underway for f26

[Björn 'besser82' Esser]

Am 01.02.2017 um 15:13 schrieb Björn 'besser82' Esser:

Am 01.02.2017 um 12:44 schrieb Tom Hughes:

On 01/02/17 11:15, Björn 'besser82' Esser wrote:

Am 01.02.2017 um 00:19 schrieb Björn 'besser82' Esser:

Am 30.01.2017 um 17:33 schrieb Jonathan Wakely:


Thanks. Several of the boost rebuilds can't proceed until hdf5 is
rebuilt. Your hdf5 build failed due to a known bug for ppc64le:
https://gcc.gnu.org/PR79197


I'll resubmit the failed hdf5-build as soon as gcc-7.0.1-0.4.fc26 with
the fix for PPC64LE has finished building.


hdf5-build just resubmitted:
https://koji.fedoraproject.org/koji/taskinfo?taskID=17540752


Unfortunately it looks like it still didn't work on ppc64le :-(

Tom



Now it's just the testsuite failing on PPC64LE; I've started a build, 
that ignores the failing testsuite on that arch for now.
A (more-or-less) working rebuild against GCC-7 of HDF5 has landed 
f26-build repo.

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

Re: F26 Self Contained Change: Container Minimal Image

[Matthew Miller]

On Wed, Feb 01, 2017 at 04:14:21PM +, Peter Robinson wrote:
> Who supports microdnf? Is that the dnf team or others?

It is the DNF team. I have a hope that these will be fronted by a
command called "yum" which will implement close-to-full compatibility
with Yum Classic, and which will:


1. Use full dnf backend if available

2. Fall back to microdnf otherwise

3. And if microdnf can't handle it, tell me so, install full dnf
   backend, and continue.

-- 
Matthew Miller

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

Re: Fedora PSM2 build failures

[Dan Horák]

On Wed, 1 Feb 2017 18:04:50 +0100
Jan Kurik  wrote:

> Hi Aravind,
> 
> there was an upgrade of GCC to version 7
> https://fedoraproject.org/wiki/Changes/GCC7 . As I can not turn the
> options off by my self, I am resending this to Release Engineering
> mailing list to consider what can be done here.

even better is the devel list, but simply the issue needs a fix on the
package level - a code update, workaround in spec file, etc


Dan
 
> Regards,
> Jan
> 
> On Wed, Feb 1, 2017 at 5:58 PM, Gopalakrishnan, Aravind
>  wrote:
> > Hi Jan,
> >
> >
> >
> > The last few nightly PSM2 builds in fedora have failed
> > (https://apps.fedoraproject.org/koschei/package/libpsm2?collection=f26).
> >
> >
> >
> > A quick check of the build logs indicate all have failed due to
> > warnings thrown by gcc (-Werror=int-in-bool-context and –
> > Werror=format-truncation)
> >
> > It seems gcc versions have changed since the last five builds and
> > likely introduced these new warning options.
> >
> > (It doesn’t fail on local builds- I have gcc v4.8.5 and it also
> > seems to have worked until gcc v6.3.1.1 as shown from the build log
> > of 2017-01-20)
> >
> >
> >
> > Would it be possible to run a quick build test of PSM2 on Fedora
> > with both the above options turned off until we work on a fix for
> > this here and test it on newer gcc versions locally?
> >
> >
> >
> > Thanks,
> >
> > -Aravind
> >
> >
> 
> 
> 
> -- 
> Jan Kuřík
> Platform & Fedora Program Manager
> Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
> ___
> rel-eng mailing list -- rel-...@lists.fedoraproject.org
> To unsubscribe send an email to rel-eng-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 Self Contained Change: Container Minimal Image

[Peter Robinson]

>>> = Proposed Self Contained Change: Container Minimal Image =
>>> https://fedoraproject.org/wiki/Changes/ContainerMinimalImage
>>>
>>> Change owner(s):
>>> * Dusty Mabe 
>>>
>>>
>>> Produce a new container image that contains as little as possible, but
>>> also still provides the ability to install packages from dnf
>>> repositories.
>>
>> How's this different to the minimal container we currently ship?
>
> The goal is to get it smaller that what we currently ship. Part of
> this is being done by removing dnf (and thus python) from the image
> by using microdnf instead. The goal really is to rip out most anything
> that doesn't make sense and/or is bloated for a container use case.

Who supports microdnf? Is that the dnf team or others?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 Self Contained Change: Container Minimal Image

[Dusty Mabe]

On 01/31/2017 09:54 AM, Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, Jan 31, 2017 at 09:00:01AM +0100, Jan Kurik wrote:
>> = Proposed Self Contained Change: Container Minimal Image =
>> https://fedoraproject.org/wiki/Changes/ContainerMinimalImage
>>
>> Change owner(s):
>> * Dusty Mabe 
>>
>>
>> Produce a new container image that contains as little as possible, but
>> also still provides the ability to install packages from dnf
>> repositories.
> 
> Would this be an official image or just a "contrib" kickstart?
> If the first, shouldn't it be added to the list of deliverables, and
> who's going to test it, etc.
> 


I would hope that this would be an official image. I imagine testing
would be a joint effort between the atomic WG and the QA team. This
is my first go-round on this front so I welcome guidance on the appropriate
process to take.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 Self Contained Change: Container Minimal Image

[Dusty Mabe]

On 01/31/2017 10:35 AM, Peter Robinson wrote:
> On Tue, Jan 31, 2017 at 8:00 AM, Jan Kurik  wrote:
>> = Proposed Self Contained Change: Container Minimal Image =
>> https://fedoraproject.org/wiki/Changes/ContainerMinimalImage
>>
>> Change owner(s):
>> * Dusty Mabe 
>>
>>
>> Produce a new container image that contains as little as possible, but
>> also still provides the ability to install packages from dnf
>> repositories.
> 
> How's this different to the minimal container we currently ship?

The goal is to get it smaller that what we currently ship. Part of
this is being done by removing dnf (and thus python) from the image
by using microdnf instead. The goal really is to rip out most anything
that doesn't make sense and/or is bloated for a container use case.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: per-product packaging question

[Stephen Gallagher]

On 02/01/2017 10:48 AM, Daniel J Walsh wrote:
> 
> 
> On 02/01/2017 09:58 AM, Stephen Gallagher wrote:
>> On 01/30/2017 05:03 PM, Vivek Goyal wrote:
>>> On Mon, Jan 30, 2017 at 05:00:34PM -0500, Lokesh Mandvekar wrote:
 Hi,

 I'm looking at the per-product packaging doc at
 https://fedoraproject.org/wiki/Packaging:Per-Product_Configuration
 and I see that variants for all products are installed at package install 
 time, with
 the ghost file pointing to the appropriate product variant.

 Just wondering if there's a reason for installing all variants and/or if 
 it's
 worth considering installation of just the particular variant appropriate 
 for
 the system at install time?
>>> We are looking at installing per-product configuration for
>>> docker-storage-setup. Now we are ending up with many configuration
>>> files.
>>>
>>> /etc/sysconfig/docker-storage-setup-default
>>> /etc/sysconfig/docker-storage-setup-server
>>> /etc/sysconfig/docker-storage-setup-workstation
>>> /etc/sysconfig/docker-storage-setup-atomic
>>> /etc/sysconfig/docker-storage-setup-cloud
>>>
>>> This really looks ugly. So question is can we just install the default
>>> and config file specific to that product and ignore rest?
>>>
>> The reason for this is because there are situations where it is impossible to
>> know what variant is in use until the %posttrans scripts have fired. (This is
>> because on initial system installation, the variant is selected when the
>> fedora-release-$EDITION package %post has been run).
>>
>> All file installation happens well before the %post and %posttrans operations
>> are run, and therefore there isn't any way to determine which file belongs on
>> the system.
>>
>> I *do* recommend that you consider moving the original, versioned config 
>> files
>> into a subdirectory somewhere and only include the `docker-storage-setup`
>> symlink in the actual end-user location.
>>
>> The reason for using symlinks rather than copies here was originally to 
>> support
>> the possibility of converting between editions (such as promoting Fedora 
>> Cloud
>> to a Fedora Server Edition) and having the configuration automatically 
>> swapped
>> for you, but that never got implemented.
>>
>> Given that this is never going to happen (we decided that changing the config
>> implicitly is a bad idea), I should update the policy to recommend using 
>> copies
>> rather than symlinks and keeping the variant configs in /usr/share instead 
>> of in
>> the /etc hierarchy.
>>
>>
>> So in this specific case, I'd recommend that you install:
>> /usr/share/docker-storage-setup/docker-storage-setup-default
>> /usr/share/docker-storage-setup/docker-storage-setup-server
>> /usr/share/docker-storage-setup/docker-storage-setup-workstation
>> /usr/share/docker-storage-setup/docker-storage-setup-atomic
>> /usr/share/docker-storage-setup/docker-storage-setup-cloud
>>
>> And then copy the appropriate one from there to
>> /etc/sysconfig/docker-storage-setup in %posttrans.
>>
>> I'll also note that you only need individual config files *if they differ*. 
>> For
>> example, if the "atomic" and "cloud" configs are identical, it's okay to skip
>> the duplication. Ditto if "default" and "server" should be the same, etc.
>>
>>
>>
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> This works for me.  As long as it is a real file and not a symlink which would
> lead to an
> admin editing files in /usr. 
> 
> The docker package should ghost the /etc/sysconfig/docker-storage-setup file 
> though.
> 


Both of those requirements are explicitly called out in the Per-Product
Configuration guidelines (as of the update I just submitted to FPC)



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: per-product packaging question

[Daniel J Walsh]

On 02/01/2017 09:58 AM, Stephen Gallagher wrote:
> On 01/30/2017 05:03 PM, Vivek Goyal wrote:
>> On Mon, Jan 30, 2017 at 05:00:34PM -0500, Lokesh Mandvekar wrote:
>>> Hi,
>>>
>>> I'm looking at the per-product packaging doc at
>>> https://fedoraproject.org/wiki/Packaging:Per-Product_Configuration
>>> and I see that variants for all products are installed at package install 
>>> time, with
>>> the ghost file pointing to the appropriate product variant.
>>>
>>> Just wondering if there's a reason for installing all variants and/or if 
>>> it's
>>> worth considering installation of just the particular variant appropriate 
>>> for
>>> the system at install time?
>> We are looking at installing per-product configuration for
>> docker-storage-setup. Now we are ending up with many configuration
>> files.
>>
>> /etc/sysconfig/docker-storage-setup-default
>> /etc/sysconfig/docker-storage-setup-server
>> /etc/sysconfig/docker-storage-setup-workstation
>> /etc/sysconfig/docker-storage-setup-atomic
>> /etc/sysconfig/docker-storage-setup-cloud
>>
>> This really looks ugly. So question is can we just install the default
>> and config file specific to that product and ignore rest?
>>
> The reason for this is because there are situations where it is impossible to
> know what variant is in use until the %posttrans scripts have fired. (This is
> because on initial system installation, the variant is selected when the
> fedora-release-$EDITION package %post has been run).
>
> All file installation happens well before the %post and %posttrans operations
> are run, and therefore there isn't any way to determine which file belongs on
> the system.
>
> I *do* recommend that you consider moving the original, versioned config files
> into a subdirectory somewhere and only include the `docker-storage-setup`
> symlink in the actual end-user location.
>
> The reason for using symlinks rather than copies here was originally to 
> support
> the possibility of converting between editions (such as promoting Fedora Cloud
> to a Fedora Server Edition) and having the configuration automatically swapped
> for you, but that never got implemented.
>
> Given that this is never going to happen (we decided that changing the config
> implicitly is a bad idea), I should update the policy to recommend using 
> copies
> rather than symlinks and keeping the variant configs in /usr/share instead of 
> in
> the /etc hierarchy.
>
>
> So in this specific case, I'd recommend that you install:
> /usr/share/docker-storage-setup/docker-storage-setup-default
> /usr/share/docker-storage-setup/docker-storage-setup-server
> /usr/share/docker-storage-setup/docker-storage-setup-workstation
> /usr/share/docker-storage-setup/docker-storage-setup-atomic
> /usr/share/docker-storage-setup/docker-storage-setup-cloud
>
> And then copy the appropriate one from there to
> /etc/sysconfig/docker-storage-setup in %posttrans.
>
> I'll also note that you only need individual config files *if they differ*. 
> For
> example, if the "atomic" and "cloud" configs are identical, it's okay to skip
> the duplication. Ditto if "default" and "server" should be the same, etc.
>
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
This works for me.  As long as it is a real file and not a symlink which
would lead to an
admin editing files in /usr. 

The docker package should ghost the /etc/sysconfig/docker-storage-setup
file though.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: Python Classroom Lab

[Stephen Gallagher]

On 02/01/2017 10:34 AM, Neal Gompa wrote:
> On Wed, Feb 1, 2017 at 10:31 AM, Stephen Gallagher  
> wrote:
>>
>> What's the advantage here vs. providing a "Python Classroom Lab" install 
>> target
>> in GNOME Software that allows you to turn any Fedora Workstation installation
>> into a Classroom Lab?
>>
> 
> GNOME Software can't do that. As far as I know, there's no
> way to expose installable groups in GNOME Software. Apper (in KDE) has
> some capability for it, but the PackageKit backend (dnf backend) has
> no support for it because it was not implemented because GNOME
> Software has no support for groups.
> 

Sure it can; you just create a metapackage that Requires/Recommends: all of the
members of the comps group and add AppData XML and a logo to that metapackage.




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: F26 System Wide Change: Python Classroom Lab

[Stephen Gallagher]

On 02/01/2017 10:34 AM, Miro Hrončok wrote:
> On 1.2.2017 16:31, Stephen Gallagher wrote:
>> On 01/31/2017 02:29 AM, Jan Kurik wrote:
>>> = System Wide Change: Python Classroom Lab =
>>> https://fedoraproject.org/wiki/Changes/PythonClassroomLab
>>>
>>> Change owner(s):
>>> * Miro Hrončok 
>>> * SIGs/Python 
>>>
>>>
>>> A new Python Classroom Lab will be created in 3 variants: Workstation
>>> based, Docker based and Vagrant based. It's an important step for our
>>> Fedora Loves Python initiative. The main audience are Python teachers
>>> and workshop instructors.
>>>
>>>
>>> == Detailed Description ==
>>> A new comps packages group with Python development tools will be
>>> created and a new Lab (or Spin) for teaching Python or Python related
>>> topics will be available from labs.fedoraproject.org as well as from
>>> the Docker Hub and Vagrant Atlas.
>>>
>>> A work in progress for the lab is available on GitHub.
>>>
>>> The Lab will contain:
>>> * Python 3.6 including the python3-devel package
>>> * Python 2.7 including the python2-devel package
>>> * PyPy 3
>>> * tox
>>> * virtualenv
>>> * IPython console for both Python 2 and 3
>>> * Jupyter Notebook with Python 2 and 3 kernels (if this gets into
>>> Fedora in time)
>>> * offline documentation for Python 2 and 3
>>> * basic toolchain for building C and C++ extensions and valgrind
>>> * git
>>> * nano, vim, ssh client, curl, wget
>>> * devel packages for commonly used dependencies of packages on the
>>> Python Package Index
>>> * * libxml2-devel
>>> * * libyaml-devel
>>> ...
>>>
>>> The Workstation based lab will also contain:
>>> * Basic GNOME
>>> * Terminal emulator
>>> * Text editor
>>> * PDF reader
>>> * Web browser
>>> * Image viewer
>>> * ...and possibly other utilities
>>>
>>> But it will not include multimedia and virtualization support, office
>>> suite, e-mail client.
>>>
>>
>>
>>
>> What's the advantage here vs. providing a "Python Classroom Lab" install 
>> target
>> in GNOME Software that allows you to turn any Fedora Workstation installation
>> into a Classroom Lab?
> 
> 1) The other two deliverables listed in the change proposal.
> 2) The ability to download an live iso and dd it to a flash drive, hand it 
> over
> to students and just works (i.e. also offline)
> 
>> Is there a specific reason you do NOT want the things you listed above?
> Yes. Make it smaller - it's a classroom lab, so no need for stuff like e-mail
> client.
> 

OK, I see why providing a Spin makes sense, but I'd still really like to see it
*also* provided as a GNOME Software install target. That way, people running
Fedora today can have an easy way to play with it without having to figure out
how to install a comps group or boot an entirely new installer.



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: F26 System Wide Change: Python Classroom Lab

[Neal Gompa]

On Wed, Feb 1, 2017 at 10:31 AM, Stephen Gallagher  wrote:
>
> What's the advantage here vs. providing a "Python Classroom Lab" install 
> target
> in GNOME Software that allows you to turn any Fedora Workstation installation
> into a Classroom Lab?
>

GNOME Software can't do that. As far as I know, there's no
way to expose installable groups in GNOME Software. Apper (in KDE) has
some capability for it, but the PackageKit backend (dnf backend) has
no support for it because it was not implemented because GNOME
Software has no support for groups.



-- 
真実はいつも一つ！/ 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: F26 System Wide Change: Python Classroom Lab

[Miro Hrončok]

On 1.2.2017 16:31, Stephen Gallagher wrote:

On 01/31/2017 02:29 AM, Jan Kurik wrote:

= System Wide Change: Python Classroom Lab =
https://fedoraproject.org/wiki/Changes/PythonClassroomLab

Change owner(s):
* Miro Hrončok 
* SIGs/Python 


A new Python Classroom Lab will be created in 3 variants: Workstation
based, Docker based and Vagrant based. It's an important step for our
Fedora Loves Python initiative. The main audience are Python teachers
and workshop instructors.


== Detailed Description ==
A new comps packages group with Python development tools will be
created and a new Lab (or Spin) for teaching Python or Python related
topics will be available from labs.fedoraproject.org as well as from
the Docker Hub and Vagrant Atlas.

A work in progress for the lab is available on GitHub.

The Lab will contain:
* Python 3.6 including the python3-devel package
* Python 2.7 including the python2-devel package
* PyPy 3
* tox
* virtualenv
* IPython console for both Python 2 and 3
* Jupyter Notebook with Python 2 and 3 kernels (if this gets into
Fedora in time)
* offline documentation for Python 2 and 3
* basic toolchain for building C and C++ extensions and valgrind
* git
* nano, vim, ssh client, curl, wget
* devel packages for commonly used dependencies of packages on the
Python Package Index
* * libxml2-devel
* * libyaml-devel
...

The Workstation based lab will also contain:
* Basic GNOME
* Terminal emulator
* Text editor
* PDF reader
* Web browser
* Image viewer
* ...and possibly other utilities

But it will not include multimedia and virtualization support, office
suite, e-mail client.





What's the advantage here vs. providing a "Python Classroom Lab" install target
in GNOME Software that allows you to turn any Fedora Workstation installation
into a Classroom Lab?


1) The other two deliverables listed in the change proposal.
2) The ability to download an live iso and dd it to a flash drive, hand 
it over to students and just works (i.e. also offline)



Is there a specific reason you do NOT want the things you listed above?
Yes. Make it smaller - it's a classroom lab, so no need for stuff like 
e-mail client.







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

Re: F26 System Wide Change: Python Classroom Lab

[Stephen Gallagher]

On 01/31/2017 02:29 AM, Jan Kurik wrote:
> = System Wide Change: Python Classroom Lab =
> https://fedoraproject.org/wiki/Changes/PythonClassroomLab
> 
> Change owner(s):
> * Miro Hrončok 
> * SIGs/Python 
> 
> 
> A new Python Classroom Lab will be created in 3 variants: Workstation
> based, Docker based and Vagrant based. It's an important step for our
> Fedora Loves Python initiative. The main audience are Python teachers
> and workshop instructors.
> 
> 
> == Detailed Description ==
> A new comps packages group with Python development tools will be
> created and a new Lab (or Spin) for teaching Python or Python related
> topics will be available from labs.fedoraproject.org as well as from
> the Docker Hub and Vagrant Atlas.
> 
> A work in progress for the lab is available on GitHub.
> 
> The Lab will contain:
> * Python 3.6 including the python3-devel package
> * Python 2.7 including the python2-devel package
> * PyPy 3
> * tox
> * virtualenv
> * IPython console for both Python 2 and 3
> * Jupyter Notebook with Python 2 and 3 kernels (if this gets into
> Fedora in time)
> * offline documentation for Python 2 and 3
> * basic toolchain for building C and C++ extensions and valgrind
> * git
> * nano, vim, ssh client, curl, wget
> * devel packages for commonly used dependencies of packages on the
> Python Package Index
> * * libxml2-devel
> * * libyaml-devel
> ...
> 
> The Workstation based lab will also contain:
> * Basic GNOME
> * Terminal emulator
> * Text editor
> * PDF reader
> * Web browser
> * Image viewer
> * ...and possibly other utilities
> 
> But it will not include multimedia and virtualization support, office
> suite, e-mail client.
> 



What's the advantage here vs. providing a "Python Classroom Lab" install target
in GNOME Software that allows you to turn any Fedora Workstation installation
into a Classroom Lab?

Is there a specific reason you do NOT want the things you listed above?




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: per-product packaging question

[Stephen Gallagher]

On 01/31/2017 09:15 AM, Daniel J Walsh wrote:
> We should just install one default in the default location,  We don't
> want to document to users the difference
> 
> During post install the content can be modified based on the package.
> 
> 

Please do not do this. It will react badly to future package upgrades. That's
the reason for the approach I wrote up in
https://fedoraproject.org/wiki/Packaging:Per-Product_Configuration which will
handle that situation properly.




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: per-product packaging question

[Stephen Gallagher]

On 02/01/2017 09:58 AM, Stephen Gallagher wrote:
> Given that this is never going to happen (we decided that changing the config
> implicitly is a bad idea), I should update the policy to recommend using 
> copies
> rather than symlinks and keeping the variant configs in /usr/share instead of 
> in
> the /etc hierarchy.
> 

As promised:
https://fedorahosted.org/fpc/ticket/675



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: per-product packaging question

[Stephen Gallagher]

On 01/30/2017 05:03 PM, Vivek Goyal wrote:
> On Mon, Jan 30, 2017 at 05:00:34PM -0500, Lokesh Mandvekar wrote:
>> Hi,
>>
>> I'm looking at the per-product packaging doc at
>> https://fedoraproject.org/wiki/Packaging:Per-Product_Configuration
>> and I see that variants for all products are installed at package install 
>> time, with
>> the ghost file pointing to the appropriate product variant.
>>
>> Just wondering if there's a reason for installing all variants and/or if it's
>> worth considering installation of just the particular variant appropriate for
>> the system at install time?
> 
> We are looking at installing per-product configuration for
> docker-storage-setup. Now we are ending up with many configuration
> files.
> 
> /etc/sysconfig/docker-storage-setup-default
> /etc/sysconfig/docker-storage-setup-server
> /etc/sysconfig/docker-storage-setup-workstation
> /etc/sysconfig/docker-storage-setup-atomic
> /etc/sysconfig/docker-storage-setup-cloud
> 
> This really looks ugly. So question is can we just install the default
> and config file specific to that product and ignore rest?
> 

The reason for this is because there are situations where it is impossible to
know what variant is in use until the %posttrans scripts have fired. (This is
because on initial system installation, the variant is selected when the
fedora-release-$EDITION package %post has been run).

All file installation happens well before the %post and %posttrans operations
are run, and therefore there isn't any way to determine which file belongs on
the system.

I *do* recommend that you consider moving the original, versioned config files
into a subdirectory somewhere and only include the `docker-storage-setup`
symlink in the actual end-user location.

The reason for using symlinks rather than copies here was originally to support
the possibility of converting between editions (such as promoting Fedora Cloud
to a Fedora Server Edition) and having the configuration automatically swapped
for you, but that never got implemented.

Given that this is never going to happen (we decided that changing the config
implicitly is a bad idea), I should update the policy to recommend using copies
rather than symlinks and keeping the variant configs in /usr/share instead of in
the /etc hierarchy.


So in this specific case, I'd recommend that you install:
/usr/share/docker-storage-setup/docker-storage-setup-default
/usr/share/docker-storage-setup/docker-storage-setup-server
/usr/share/docker-storage-setup/docker-storage-setup-workstation
/usr/share/docker-storage-setup/docker-storage-setup-atomic
/usr/share/docker-storage-setup/docker-storage-setup-cloud

And then copy the appropriate one from there to
/etc/sysconfig/docker-storage-setup in %posttrans.

I'll also note that you only need individual config files *if they differ*. For
example, if the "atomic" and "cloud" configs are identical, it's okay to skip
the duplication. Ditto if "default" and "server" should be the same, etc.



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

Orphaned Packages in rawhide (2017-02-01)

[opensource]

The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

  Package(co)maintainers  Status Change 
===
GLee   orphan 12 weeks ago  
PyKDE  orphan, group::kde-sig,0 weeks ago   
   jamatos, rdieter 
PyQt   orphan, rdieter, than  0 weeks ago   
amplab-tachyon orphan, hchen, java-sig,   2 weeks ago   
   tstclair 
apache-log4j-extrasorphan, coolsvap, gil, java-   2 weeks ago   
   sig, moceap, rrati   
budgie orphan, cicku, 2 weeks ago   
   williamjmorenor, zsun
caml-crush orphan, nmav   7 weeks ago   
chatzilla  orphan 12 weeks ago  
condor-ec2-enhancedorphan, rrati  2 weeks ago   
condor-ec2-enhanced-hooks  orphan, rrati  2 weeks ago   
condor-job-hooks   orphan, rrati  2 weeks ago   
condor-low-latency orphan, rrati  2 weeks ago   
cssed  orphan, affix  1 weeks ago   
diodon orphan 7 weeks ago   
farstream  orphan, amigadave, 7 weeks ago   
   mooninite, uraeus, vicodan   
freetalk   orphan, cicku  7 weeks ago   
greenmail  orphan, gil, java-sig, 2 weeks ago   
   moceap, rrati
jamon-api  orphan, gil, java-sig, 2 weeks ago   
   moceap, rrati
jamon-java-parent  orphan, gil, java-sig, 2 weeks ago   
   moceap, rrati
jamon-maven-plugin orphan, gil, java-sig, 2 weeks ago   
   moceap, rrati
jamon-nodegen-plugin   orphan, gil, java-sig, 2 weeks ago   
   moceap, rrati
jamon-parent   orphan, gil, java-sig, 2 weeks ago   
   moceap, rrati
jamon-processororphan, gil, java-sig, 2 weeks ago   
   moceap, rrati
jamon-runtime  orphan, gil, java-sig, 2 weeks ago   
   moceap, rrati
jspeex orphan 12 weeks ago  
jung   orphan, coolsvap, moceap,  2 weeks ago   
   rrati
kfilemetadata  orphan, group::kde-sig,0 weeks ago   
   jgrulich, jreznik, nucleo,   
   rdieter, than
libaudclient   orphan, sergiomb   5 weeks ago   
libgnome-media-profilesorphan, hadess, yaneti 3 weeks ago   
mingw-gtkhtml3 orphan, epienbro   3 weeks ago   
mingw-libgnurx orphan, epienbro, rjones   3 weeks ago   
mingw-winstorecompat   orphan, epienbro, ktietz   3 weeks ago   
mj orphan, goeran 3 weeks ago   
nautilus-terminal  orphan, hicham 12 weeks ago  
nntpgrab   orphan, epienbro   3 weeks ago   
ocaml-config-file  orphan, nmav   7 weeks ago   
open-nat   orphan 12 weeks ago  
openclipartorphan 4 weeks ago   
php-IDNA_Convert   orphan, ke4qqq 3 weeks ago   
php-channel-htmlpurifier

Maven downgrade to 3.3.9 in rawhide

[Michael Šimáček]

Hi fellow packagers,

In the beginning of this year, maven upstream announced [1] they dropped 
3.4.0 release and reverted the changes made. We already had 3.4.0 
snapshot in Fedora Rawhide, so this means we have to revert maven 
package back to version 3.3.9.


[1] 
https://mail-archives.apache.org/mod_mbox/maven-announce/201701.mbox/%3CCA%2BnPnMzNjwTi3A7LoB3whNXyrz%3DS7gbROHOd-oyciu6f0EbPLA%40mail.gmail.com%3E


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

Re: Boost 1.63 rebuilds underway for f26

[Björn 'besser82' Esser]

Am 01.02.2017 um 12:44 schrieb Tom Hughes:

On 01/02/17 11:15, Björn 'besser82' Esser wrote:

Am 01.02.2017 um 00:19 schrieb Björn 'besser82' Esser:

Am 30.01.2017 um 17:33 schrieb Jonathan Wakely:


Thanks. Several of the boost rebuilds can't proceed until hdf5 is
rebuilt. Your hdf5 build failed due to a known bug for ppc64le:
https://gcc.gnu.org/PR79197


I'll resubmit the failed hdf5-build as soon as gcc-7.0.1-0.4.fc26 with
the fix for PPC64LE has finished building.


hdf5-build just resubmitted:
https://koji.fedoraproject.org/koji/taskinfo?taskID=17540752


Unfortunately it looks like it still didn't work on ppc64le :-(

Tom



Now it's just the testsuite failing on PPC64LE; I've started a build, 
that ignores the failing testsuite on that arch for now.

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

Fedora Rawhide-20170201.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Cloud_base qcow2 x86_64
Kde live x86_64
Cloud_base raw-xz x86_64
Xfce raw-xz armhfp
Minimal raw-xz armhfp
Kde live i386

Failed openQA tests: 13/96 (x86_64), 1/17 (i386)

ID: 55953   Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/55953
ID: 55955   Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/55955
ID: 55957   Test: x86_64 Server-dvd-iso server_cockpit_default
URL: https://openqa.fedoraproject.org/tests/55957
ID: 55961   Test: x86_64 Server-dvd-iso server_role_deploy_database_server
URL: https://openqa.fedoraproject.org/tests/55961
ID: 55972   Test: x86_64 Workstation-live-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/55972
ID: 55975   Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/55975
ID: 55979   Test: x86_64 Workstation-live-iso 
desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/55979
ID: 56010   Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/56010
ID: 56016   Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/56016
ID: 56030   Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/56030
ID: 56043   Test: x86_64 universal install_rescue_encrypted
URL: https://openqa.fedoraproject.org/tests/56043
ID: 56044   Test: x86_64 universal install_rescue_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/56044
ID: 56055   Test: i386 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/56055
ID: 56056   Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/56056

Soft failed openQA tests: 53/96 (x86_64), 11/17 (i386)
(Tests completed, but using a workaround for a known bug)

ID: 55943   Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/55943
ID: 55944   Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/55944
ID: 55945   Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/55945
ID: 55946   Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/55946
ID: 55954   Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/55954
ID: 55963   Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/55963
ID: 55964   Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/55964
ID: 55965   Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/55965
ID: 55966   Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/55966
ID: 55967   Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/55967
ID: 55968   Test: i386 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/55968
ID: 55988   Test: x86_64 universal install_repository_http_variation
URL: https://openqa.fedoraproject.org/tests/55988
ID: 55989   Test: x86_64 universal install_repository_http_graphical
URL: https://openqa.fedoraproject.org/tests/55989
ID: 55990   Test: x86_64 universal install_mirrorlist_graphical
URL: https://openqa.fedoraproject.org/tests/55990
ID: 55991   Test: x86_64 universal install_delete_pata
URL: https://openqa.fedoraproject.org/tests/55991
ID: 55992   Test: x86_64 universal install_delete_pata@uefi
URL: https://openqa.fedoraproject.org/tests/55992
ID: 55993   Test: x86_64 universal install_sata
URL: https://openqa.fedoraproject.org/tests/55993
ID: 55994   Test: x86_64 universal install_sata@uefi
URL: https://openqa.fedoraproject.org/tests/55994
ID: 55995   Test: x86_64 universal install_kickstart_user_creation
URL: https://openqa.fedoraproject.org/tests/55995
ID: 55996   Test: x86_64 universal install_scsi_updates_img
URL: https://openqa.fedoraproject.org/tests/55996
ID: 55997   Test: x86_64 universal install_multi
URL: https://openqa.fedoraproject.org/tests/55997
ID: 55998   Test: x86_64 universal install_multi@uefi
URL: https://openqa.fedoraproject.org/tests/55998
ID: 56000   Test: x86_64 universal install_no_swap@uefi
URL: https://openqa.fedoraproject.org/tests/56000
ID: 56001   Test: x86_64 universal install_kickstart_hdd
URL: https://openqa.fedoraproject.org/tests/56001
ID: 56002   Test: x86_64 universal upgrade_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/56002
ID: 56004   Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/56004
ID: 56007   Test: x86_64 universal upgrade_2_minimal_64bit
URL

Re: flatpak app launch script

[Martin Kolman]

On Wed, 2017-02-01 at 07:16 -0600, Michael Catanzaro wrote:
> On Wed, 2017-02-01 at 13:46 +0100, Martin Kolman wrote:
> > Can you pass command line arguments like this ? For example
> > inkscape
> > can be used not only as a GUI app, but also from the command line
> > to
> > convert SVG files to PNG and other things. So it would be good if
> > flatpack can also support that.
> 
> Yes. Arguments to flatpak go before the name of the app to launch,
> arguments to the app go after.
Nice! It's good to know it already works. :)

BTW, what about sandboxing & file access ?

Let's say I try to run (a hypothetical) example:

flatpak run com.example.inkscape --svg-to-png /home/user/foo.svg

As the file is outside of the sandbox what will happen ? Will it fail
to access the file or will the user be asked to confirm access to it ? 

I guess one could also just enable $HOME access for the app in a case
like this, but still.
> 
> Michael
> ___
> 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: flatpak app launch script

[Michael Catanzaro]

On Wed, 2017-02-01 at 13:46 +0100, Martin Kolman wrote:
> Can you pass command line arguments like this ? For example inkscape
> can be used not only as a GUI app, but also from the command line to
> convert SVG files to PNG and other things. So it would be good if
> flatpack can also support that.

Yes. Arguments to flatpak go before the name of the app to launch,
arguments to the app go after.

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

Re: Rust SIG

[Neal Gompa]

On Wed, Feb 1, 2017 at 8:02 AM, Jan Synacek  wrote:
> On Mon, Jan 30, 2017 at 9:03 AM, Igor Gnatenko
>  wrote:
>> Hello everybody,
>>
>> we are establishing new SIG for Rust[0]. Feel free to join us on IRC
>> (#fedora-rust) and/or Mailing List (r...@lists.fedoraproject.org).
>>
>> Help with improving our wiki page is very welcomed ;)
>>
>> [0] https://fedoraproject.org/wiki/SIGs/Rust
>
> Hi,
>
> I have a couple of questions. The description on the SIG page says:
>
> "This includes packaging Rust libraries and applications, setting and
> improving standards for packaging them as RPM's and maintaining Rust
> packages for Fedora."
>
> Isn't packaging Rust libraries waste of time? Cargo does a great job
> taking care of the libraries / dependencies.
>

Cargo requires internet access unless a local repository of the
dependencies can be found. We cannot build Rust applications that
depend on crates in Fedora infrastructure without them packaged first.
In this regard, we will be mimicking the strategy employed by the
golang packaging, and crates will be -devel only, including only
source code.

> How is packaging Rust applications different from packaging any
> compiled (to ELF) applications? Apart from having the correct runtime,
> of course.
>

Well, for one, we have to deal with Cargo. Most of what we're doing is
ensuring Cargo plays nice with the restrictions we have.


-- 
真実はいつも一つ！/ 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: Rust SIG

[Jan Synacek]

On Mon, Jan 30, 2017 at 9:03 AM, Igor Gnatenko
 wrote:
> Hello everybody,
>
> we are establishing new SIG for Rust[0]. Feel free to join us on IRC
> (#fedora-rust) and/or Mailing List (r...@lists.fedoraproject.org).
>
> Help with improving our wiki page is very welcomed ;)
>
> [0] https://fedoraproject.org/wiki/SIGs/Rust

Hi,

I have a couple of questions. The description on the SIG page says:

"This includes packaging Rust libraries and applications, setting and
improving standards for packaging them as RPM's and maintaining Rust
packages for Fedora."

Isn't packaging Rust libraries waste of time? Cargo does a great job
taking care of the libraries / dependencies.

How is packaging Rust applications different from packaging any
compiled (to ELF) applications? Apart from having the correct runtime,
of course.

Cheers,
-- 
Jan Synacek
Software Engineer, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Boost 1.63 rebuilds underway for f26

[Ralf Corsepius]

On 02/01/2017 12:44 PM, Tom Hughes wrote:

On 01/02/17 11:15, Björn 'besser82' Esser wrote:

Am 01.02.2017 um 00:19 schrieb Björn 'besser82' Esser:

Am 30.01.2017 um 17:33 schrieb Jonathan Wakely:


Thanks. Several of the boost rebuilds can't proceed until hdf5 is
rebuilt. Your hdf5 build failed due to a known bug for ppc64le:
https://gcc.gnu.org/PR79197


I'll resubmit the failed hdf5-build as soon as gcc-7.0.1-0.4.fc26 with
the fix for PPC64LE has finished building.


hdf5-build just resubmitted:
https://koji.fedoraproject.org/koji/taskinfo?taskID=17540752


Unfortunately it looks like it still didn't work on ppc64le :-(


The same for openblas:
https://koji.fedoraproject.org/koji/taskinfo?taskID=17541487

Ralf

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

Re: flatpak app launch script

[Martin Kolman]

On Wed, 2017-02-01 at 10:05 +0100, Martin Stransky wrote:
> Hi,
> 
> I feel that launching a flatpak app from command line a bit
> regression 
> from rpm packages. It's really different to type:
> 
> $firefox
> 
> or
> 
> $flatpak run org.mozilla.Firefox
Can you pass command line arguments like this ? For example inkscape
can be used not only as a GUI app, but also from the command line to
convert SVG files to PNG and other things. So it would be good if
flatpack can also support that.

> 
> Especially when "flatpak run org.mozilla" carries no information for 
> user, they just want to launch the app and don't care if that's rpm, 
> flatpak, snap or whatever. The ALT+F2 is affected too by this.
> 
> And why to care about about command line anyway? I think we should 
> match it with existing rpm system as much as possible.
> 
> To match flatpak usability with rpm packages, can there be a launch 
> script (say in /var/lib/flatpak/bin to keep it consistent) like we
> have 
> in /usr/bin? I expect that launch script should be owned by flatpak
> app, 
> optional.
> 
> Thoughts?
> Ma.
> ___
> 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: flatpak app launch script

[Benjamin Kircher]

Hi!

>> Hi,
>> 
>> I feel that launching a flatpak app from command line a bit regression
>> from rpm packages. It's really different to type:
>> 
>> $firefox
>> 
>> or
>> 
>> $flatpak run org.mozilla.Firefox
>> 
>> Especially when "flatpak run org.mozilla" carries no information for
>> user, they just want to launch the app and don't care if that's rpm,
>> flatpak, snap or whatever. The ALT+F2 is affected too by this.
>> 
>> And why to care about about command line anyway? I think we should
>> match it with existing rpm system as much as possible.
>> 
>> To match flatpak usability with rpm packages, can there be a launch
>> script (say in /var/lib/flatpak/bin to keep it consistent) like we have
>> in /usr/bin? I expect that launch script should be owned by flatpak app,
>> optional.
> 
> "firefox" is not namespaced, Flatpak, for security reasons, only exports
> namespaced data, so as to avoid clashes. This is one of the reasons why
> you can easily install Nightly and stable versions of apps.
> 
> I think most of our users do not launch Firefox from the command-line,
> and the few that do would likely know how to create a shell script.
> 
> The important thing is that clicking on links has the expected result,
> launching the default browser. You can select it through "Settings ->
> Details -> Default Applications".

And of course you can always do

$ alias firefox='$flatpak run org.mozilla.Firefox'

in bash and other shells or use xdg-open from xdg-utils package if you want.

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

Re: F26 Self Contained Change: Anaconda LVM RAID

[David Woodhouse]

On Tue, 2017-01-31 at 13:13 +0100, Jan Kurik wrote:
> = Proposed Self Contained Change: Anaconda LVM RAID =
> https://fedoraproject.org/wiki/Changes/AnacondaLVMRAID
> 
> Change owner(s):
> * Vratislav Podzimek (Anaconda/Blivet) 
> * Heinz Mauelshagen (LVM) 
> 
> Use LVM RAID instead of LVM of top of MD RAID in the Anaconda
> installer.
> 
> 
> == Detailed Description ==
> In the current situation when a user chooses LVM (or Thin LVM)
> partitioning in the Custom Spoke and then sets RAID level for the VG
> Anaconda (and Blivet) create an MD RAID device which is used as a PV
> for the VG. With this change we are going to use LVM RAID directly
> instead. That means that all the LVs in that VG will be RAID LVs with
> the specified RAID level. LVM RAID provides same functionality as MD
> RAID (it shares the same kernel code) with better flexibility and
> additional features expected in future.
> 
> 
> 
> == Scope ==
> * Proposal owners:
> -- Blivet developers: Support creation of LVM RAID in a similar way
> as
> LVM on top of MD RAID. (Creation of RAID LVs is already supported.)
> -- Anaconda developers: Use the new way to create LVM RAID instead of
> creating LVM on top of MD RAID.
> -- LVM developers: LVM RAID already has all features required by this
> change.
> 
> * Other developers:
> N/A (not a System Wide Change)
> 
> * Release engineering:

Please ensure upgrades of systems using MD RAID are properly tested.

My server at home broke on upgrading to Fedora 22 (#1201962), and also
on upgrading to Fedora 20 before that (IIRC). This implies that even
when MD RAID was still being used by default, upgrades weren't very
well-tested. With a move away from MD to LVM RAID, I'm concerned that
things will only get worse. So let's please ensure that we have proper
test coverage for existing systems.


smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Boost 1.63 rebuilds underway for f26

[Tom Hughes]

On 01/02/17 11:15, Björn 'besser82' Esser wrote:

Am 01.02.2017 um 00:19 schrieb Björn 'besser82' Esser:

Am 30.01.2017 um 17:33 schrieb Jonathan Wakely:


Thanks. Several of the boost rebuilds can't proceed until hdf5 is
rebuilt. Your hdf5 build failed due to a known bug for ppc64le:
https://gcc.gnu.org/PR79197


I'll resubmit the failed hdf5-build as soon as gcc-7.0.1-0.4.fc26 with
the fix for PPC64LE has finished building.


hdf5-build just resubmitted:
https://koji.fedoraproject.org/koji/taskinfo?taskID=17540752


Unfortunately it looks like it still didn't work on ppc64le :-(

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

F26 Self Contained Change: LDC 1.1.0

[Jan Kurik]

= Proposed Self Contained Change: LDC 1.1.0 =
https://fedoraproject.org/wiki/Changes/LDC1.1.0

Change owner(s):
* Kalev Lember 

Update LDC to 1.1.0 in Fedora 26.


== Detailed Description ==
The LDC D compiler has been lagging behind upstream in Fedora, making
it difficult to build software that needs an up to date D compiler,
such as Terminix. With this update, LDC in Fedora gets bumped to the
latest upstream release, 1.1.0, and hopefully makes it easier for
projects using the D compiler to get into Fedora.


== Scope ==
* Proposal owners:
-- Update LDC to 1.1.0 [done]
-- Add an %{ldc_arches} RPM macro that dependant packages can use to
correctly set ExclusiveArch [done]
-- Rebuild packages depending on LDC [done]

* Other developers:
N/A (not a System Wide Change)

* Release engineering:
N/A

* List of deliverables:
N/A (not a System Wide Change)

* Policies and guidelines:
N/A (not a System Wide Change)

* Trademark approval:
N/A (not needed for this Change)
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Boost 1.63 rebuilds underway for f26

[Björn 'besser82' Esser]

Am 01.02.2017 um 00:19 schrieb Björn 'besser82' Esser:

Am 30.01.2017 um 17:33 schrieb Jonathan Wakely:

On 30/01/17 12:34 +0100, Björn 'besser82' Esser wrote:

Am 27.01.2017 um 13:12 schrieb Jonathan Wakely:

On 27/01/17 13:02 +0100, Björn 'besser82' Esser wrote:

Am 27.01.2017 um 12:21 schrieb Jonathan Wakely:

As part of the https://fedoraproject.org//wiki/Changes/F26Boost163
change to update Boost in F26 I've started rebuilding the packages
that depend on Boost, using the f26-boost side tag. That means I've
pushed a bumpspec change to their spec files, but the rebuilt 
package

won't land in rawhide until they're all done and everything in the
side tag is merged back to the main f26 target.

If you maintain a package that depends on Boost and this will
interfere with any package maintenance you're doing please let me 
know

and I'll coordinate the rebuilds with you.

I'm trying to get all these rebuilds done before the mass rebuild 
next

week, but as usual there will be lots of FTBFS cases.


There will be a new release for SWIG during today.  Please don't 
rebuild SWIG for now.  I'll take care to have it built in the 
side-tag properly.


OK, thanks.

Swig is properly build in f26-boost now.


Thanks. Several of the boost rebuilds can't proceed until hdf5 is
rebuilt. Your hdf5 build failed due to a known bug for ppc64le:
https://gcc.gnu.org/PR79197


I'll resubmit the failed hdf5-build as soon as gcc-7.0.1-0.4.fc26 with 
the fix for PPC64LE has finished building.


hdf5-build just resubmitted: 
https://koji.fedoraproject.org/koji/taskinfo?taskID=17540752

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

Re: flatpak app launch script

[Bastien Nocera]

- Original Message -
> Hi,
> 
> I feel that launching a flatpak app from command line a bit regression
> from rpm packages. It's really different to type:
> 
> $firefox
> 
> or
> 
> $flatpak run org.mozilla.Firefox
> 
> Especially when "flatpak run org.mozilla" carries no information for
> user, they just want to launch the app and don't care if that's rpm,
> flatpak, snap or whatever. The ALT+F2 is affected too by this.
> 
> And why to care about about command line anyway? I think we should
> match it with existing rpm system as much as possible.
> 
> To match flatpak usability with rpm packages, can there be a launch
> script (say in /var/lib/flatpak/bin to keep it consistent) like we have
> in /usr/bin? I expect that launch script should be owned by flatpak app,
> optional.

"firefox" is not namespaced, Flatpak, for security reasons, only exports
namespaced data, so as to avoid clashes. This is one of the reasons why
you can easily install Nightly and stable versions of apps.

I think most of our users do not launch Firefox from the command-line,
and the few that do would likely know how to create a shell script.

The important thing is that clicking on links has the expected result,
launching the default browser. You can select it through "Settings ->
Details -> Default Applications".
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Offering to co maintain lv2 related packages (lv2, lilv, suil, serd, sord, sratom...)

[Guido Aulisi]

> Il giorno 25 gen 2017, alle ore 10:57, Simone Caronni  
> ha scritto:
> 
> Hello,
> 
> On Wed, Jan 25, 2017 at 9:36 AM, Guido Aulisi  > wrote:
> Hello,
> I recently joined the packager group and I made 2 audio related
> packages (setBfree and lv2-ir-plugins).
> I noticed that lv2 related packages are behind upstream releases, and I
> know there are important bug fixes in these new releases, so I'm
> proposing myself as a co-maintainer of lv2 related packages (from
> drobilla.net ) to try to package the latest versions 
> (in rawhide).
> The packages are:
> 
> lv2
> sratom
> serd
> sord
> suil
> lilv
> 
> I'm requiring the epel7 ones, so I requested branches for some of them a few 
> months ago. Count me in if you need additional maintainership, would be nice 
> to make sure the packages build also on el7 so we can just merge the commits 
> in the various branches.

How did you make the request? Did you contact the maintainers directly?
Are there any news?

Thanks

> Thanks,
> --Simone
> 
> 
>  
> 
> Ciao
> Guido
> ___
> devel mailing list -- devel@lists.fedoraproject.org 
> 
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org 
> 
> 
> 
> 
> 
> -- 
> You cannot discover new oceans unless you have the courage to lose sight of 
> the shore (R. W. Emerson).
> 
> http://xkcd.com/229/ 
> http://negativo17.org/ 
> ___
> devel mailing list -- devel@lists.fedoraproject.org 
> 
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org 
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Orphaning rubygem-logging

[Vít Ondruch]

Hi,

I just updated and fixed rubygem-logging, but since I have no use for
this package, I just orphaned it in PkgDb. Feel free to pick it up or
let it go away ...


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

Re: Self Introduction: Darryl T. Agostinelli

[Charalampos Stratakis]

Hello and welcome to Fedora!

Charalampos Stratakis
Associate Software Engineer
Python Maintenance Team, Red Hat


- Original Message -
From: "Darryl T. Agostinelli" 
To: devel@lists.fedoraproject.org
Sent: Wednesday, February 1, 2017 5:30:28 AM
Subject: Self Introduction: Darryl T. Agostinelli

Hello All,
My name is Darryl T. Agostinelli.  I am a professional programmer and I
work for myself.

I have been a Linux user since the 1990's and have been itching for
years to author a package and contribute it to the community that has
provided me with so much.  Thank you all for the work that you have done
to enrich my life over all these years.  The time has finally come. 

My professional work has varied greatly over the years.  Currently, I'm
involved in run-of-the-mill things like a database migration, a firmware
project (that one has been a blast) and an intranet application.  The
project list changes quite often.  I've worked in so many industries and
on so many projects.  I've had a great time of it all.  My core
competencies are extremely varied.  As for languages, the list of
languages that I have a high degree of competency in include Pure-C as
well as C++, Python, C#, Javascript, Visual Basic and now Lua.  From the
language list, you might be able to tell that I've worked a lot in
Windows as well as Linux.

I think of myself as a lifetime learner.  I built hypatia (the math
library that I'm submitting today) to teach myself some linear algebra
as well as computer graphics topics.  I built it because I wasn't happy
about the available pure-C options for 3D-math available (and it also
afforded me an opportunity to write something for the community)  I am
also working through the Eudyptula Challenge. I'm up to task 14.  A few
months ago, I had my first few (albeit trivial) patches accepted to the
Linux Kernel.

I am active in my local community here in Austin, Texas.  I maintain a
private email list for other local programmers to share ideas.  I also
teach the computer science class at a local parochial high school, I
mentor some aspiring programmers (high school students), I co-coach
soccer and I also lead a group of Cub Scouts.

I am hoping to become sponsored and then I hope to have my project
become part of Fedora Linux.

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

Many Kind Regards,
Darryl T. Agostinelli
___
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

flatpak app launch script

[Martin Stransky]

Hi,

I feel that launching a flatpak app from command line a bit regression 
from rpm packages. It's really different to type:


$firefox

or

$flatpak run org.mozilla.Firefox

Especially when "flatpak run org.mozilla" carries no information for 
user, they just want to launch the app and don't care if that's rpm, 
flatpak, snap or whatever. The ALT+F2 is affected too by this.


And why to care about about command line anyway? I think we should 
match it with existing rpm system as much as possible.


To match flatpak usability with rpm packages, can there be a launch 
script (say in /var/lib/flatpak/bin to keep it consistent) like we have 
in /usr/bin? I expect that launch script should be owned by flatpak app, 
optional.


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

Re: packaging work is becoming increasingly cumbersome

[Lubomír Sedlář]

Kevin Fenzi píše v Út 31. 01. 2017 v 16:19 -0700:
> On Tue, 31 Jan 2017 23:26:29 +0100
> Julian Sikorski  wrote:
> 
> > - chain-building has been broken for a month [2] so now requesting
> > each build in the chain separately is required
> 
> I just did a ping on that issue. Hopefully we can get a new release
> out with the fix soon. I know rdieter made a local patch he's been
> using fine, so this really should not be that hard to push out. 

We've had the patch for some time now, but due to churn around DevConf
did not manage to get them out yet. I just made the builds and
submitted updates. Please try them out and give feedback.

https://bodhi.fedoraproject.org/updates/FEDORA-2017-a11eb3284c
https://bodhi.fedoraproject.org/updates/FEDORA-2017-6808c6d2dc
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-209d47f2aa
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-b65a190953

Make sure to install both pyrpkg and fedpkg from the update, otherwise
the fix will not work (but nothing else should break).

> > - fedpkg now needs authentication via kerberos instead of ssh key
> > [3],
> > which means that I now have to run kinit before starting a
> > packaging
> > session, in addition to firing up keepass and entering the password
> 
> Yeah. This will hopefully be helped by the upcoming kerberos cache
> change. 

Or you could set up Gnome Online Accounts and it will get the ticket
for you automatically.

-- 
Lubomír Sedlář 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org