gcc 5.2
by Xose Vazquez Perez
Hi,
Will it be updated/included in F23?
troubles with ARM?
-thanks-
8 years, 5 months
Ownership of /usr/lib/rpm/fileattrs
by Orion Poplawski
Various packages now install files into /usr/lib/rpm/fileattrs for use when
building rpms. Currently that directory is owned by:
rpm-build-4.13.0-0.rc1.4.fc23.x86_64
javapackages-tools-4.6.0-6.fc23.noarch
Of the various packages on my machine that install files there:
gstreamer1-1.6.0-2.fc23.x86_64
javapackages-tools-4.6.0-6.fc23.noarch
kde-settings-23-7.fc23.noarch
nodejs-0.10.36-4.fc23.x86_64
perl-generators-1.06-1.fc23.noarch
python3-cups-1.9.72-2.fc23.x86_64
redhat-rpm-config-36-1.fc23.noarch
rpm-build-4.13.0-0.rc1.4.fc23.x86_64
rpm-mpi-hooks-3-2.fc23.noarch
only rpm-mpi-hooks requires rpm-build for directory ownership, while
javapackages-tools takes the route of owning the directory. However, I'd
rather rpm-mpi-hooks not require rpm-build as it's not really necessary other
than for this directory. The simple thing I think would be for rpm to own the
directory. Does that seem reasonable?
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 http://www.nwra.com
8 years, 5 months
Distributions Devroom CFP
by Brian Stinson
FOSDEM 2016 - Distributions Devroom Call for Participation
The Distributions devroom will take place 30 & 31 January, 2016 at FOSDEM, in
room K.4.201 at Université Libre de Bruxelles, in Brussels, Belgium.
As Linux distributions converge on similar tools, the problem space overlapping
different distributions is growing. This standardization across the
distributions presents an opportunity to develop generic solutions to the
problems of aggregating, building, and maintaining the pieces that go into a
distribution.
We welcome submissions targeted at developers interested in issues unique to
distributions, especially in the following topics:
- Cross-distribution collaboration on common issues, eg: content distribution and documentation
- Working with vendor relationships (eg. cloud providers, non-commodity hardware vendors etc )
- The future of distributions, emerging trends and evolving user demands from the idea of a platform
- User experience management ( onboarding new users, facilitating technical growth, user to contribution transitions etc )
- Building trust and code relationships with the upstream components of a distribution
- Solving traditional problems like package management, and content management (eg. rpm/dpkg/ostree/coreos )
- Contributor resource management, centralised trust management, key trust etc
- Integration technologies like installers, deployment facilitation ( eg. cloud contextualisation )
Submissions may be in the form of 30-55 minute talks, panel sessions,
round-table discussions, Birds of a Feather (BoF) sessions or lightning talks.
Dates
------
Submission Deadline: 10th Dec 2015
Acceptance Notification: 15th Dec 2015
Final Schedule Posted: 17th Dec 2015
How to submit
--------------
Visit https://penta.fosdem.org/submission/FOSDEM16
1.) If you do not have an account, create one here
2.) Click 'Create Event'
3.) Enter your presentation details
4.) Be sure to select the Distributions Devroom track!
5.) Submit
What to include
---------------
- The title of your submission
- A 1-paragraph Abstract
- A longer description including the benefit of your talk to your target audience
- Approximate length / type of submission (talk, BoF, ...)
- Links to related websites/blogs/talk material (if any)
If you have any questions, feel free to contact the devroom organizers:
distributions-devroom(a)lists.fosdem.org (https://lists.fosdem.org/listinfo/distributions-devroom)
Cheers!
Karanbir Singh (twitter: @kbsingh) and Brian Stinson (twitter: @bstinsonmhk)
for and on behalf of The Distributions Devroom Program Committee
8 years, 5 months
Re: [HEADS UP] Upcoming soname change for libtirpc
by Steve Dickson
On 11/02/2015 03:32 PM, Adam Williamson wrote:
> On Mon, 2015-11-02 at 14:59 -0500, Steve Dickson wrote:
>
>>> Folks, this is not okay. This is not the right way to do things. If
>>> you
>>> aren't reasonably sure that all the library's consumers can be made
>>> to
>>> work with the new version of the library, *don't put the new
>>> version in
>>> Rawhide*. Rawhide isn't a dumping ground for random new code and
>>> has
>>> not been for some time. It is not okay to just break the entire
>>> thing
>>> and say 'we'll fix it once we've finished the upstream work'. The
>>> upstream work needs to happen *before* you break Rawhide.
>>>
>>> We're doing all this work across several teams to compose and test
>>> Rawhide regularly, and it's kind of pointless if people are just
>>> going
>>> to break the whole thing gratuitously. Please do not do this.
>>>
>>> Policy:
>>>
>>> https://fedoraproject.org/wiki/Updates_Policy#Rawhide_.2F_devel_.2F
>>> _master
>> Boy... I sure wish this policy was pointed out earlier...
>> I had no idea that existed.. I realize ignorances is not an excuse
>> so for that I do apologize..
>
> Thanks a lot. It just is a bit frustrating to multiple teams -
> anaconda, QA, and releng are all working on making Rawhide more of a
> known quantity, and this kind of things breaks it for all of us.
>
>>> Note that that clearly says "A week in advance, notify maintainers
>>> who
>>> depend on their package to rebuild when there are abi/api changes
>>> that
>>> require rebuilds in other packages or offer to do these rebuilds
>>> for
>>> them." *A WEEK IN ADVANCE*. This bump was submitted to Koji on the
>>> *same day* it was notified, 2015-10-30.
>> To be clear.. I should have waited a week after I sent this mail to
>> bump the version, correct? If so what could the maintainers do during
>> that week to make things smother?
>
> Yes. What could - and should - happen during the week is you could run
> test builds of the affected packages, and find these problems, and then
> hold off on doing the build in Rawhide until resolutions were
> available. There are various strategies for that. The casual way I'd do
> it would be to do a scratch build of libtirpc , download the results,
> make a side repository, and do mock builds of the dependent packages.
> It's easy to create a mock target which uses a local side repository:
> you just copy the config file for an existing target and add an
> additional repository definition to it right at the bottom, above the
> closing """, like this:
>
> [side]
> baseurl=file:///home/adamw/local/repo2/x86_64
> enabled=1
Ah... this is a good idea... I wish I would have thought of it.
> """
>
> That's from my 'Rawhide with a side repo' target definition file,
> /etc/mock/fedora-rawhide-x86_64-side.cfg . Mock target names are the
> basenames of the config file, so to do a build against that target I'd
> do:
>
> mock -r fedora-rawhide-x86_64-side --rebuild some.src.rpm
>
> I'd have the packages I wanted to build against in
> /home/adamw/local/repo2/x86_64 and I'd have run 'createrepo .' in that
> directory.
>
> You can also request a tag from releng for doing significant bump-and-
> rebuild operations like this; that's basically a sorta playground space
> in Koji, you can do a build of the soname-bumped library in the tag and
> then try building all the dependent packages in the same tag, and none
> of the stuff will ever appear in the official repos, unless you
> manually tag it across once you're happy with it. Finally, you could
> use COPR - just create a COPR, do the soname bumped build, and try
> building all the deps in the same COPR. That might be the easiest way.
>
Boy... I do wish we had the conversation two days ago! :-)
I really didn't have any ideas on how to do this gracefully,
which was the purpose of this email to be begin with...
I've changed soname in the past so I know how painful it
can be...
Last week, instead of us talking about graphics cards and
gaming machines... maybe we should have been talking about
soname changes! ;-)
steved.
P.S I am working feverishly on trying to Humpty Dumpty
back together again!
8 years, 5 months
Fedora Developer Portal - released !!!!
by Petr Hracek
Hello folks,
I am happy to announce that Fedora Developer Portal is released.
Official web address is http://developer.fedoraproject.org.
Official ticket on Fedora infrastructure is here [1]. Thanks to kevin
from Fedora Infrastructure team.
And Mairin Duffy for design the portal from scratch
Developing instance is located here [2].
*Fedora developer portal:*
The aim of the portal is to give an overview about important development
tools and projects in Fedora (like Docker, Vagrant, DevAssistant).
Focus is targeted on beginners, advanced users and developers.
*Who will use the portal?*
Fedora developer portal shows users how to develop on Fedora easily, and
of course introduces them to new projects and tools that are available
in Fedora.
Fedora users will have and overview about:
- new technologies
- available developer languages
- projects released in each Fedora release cycle
- import tools in Fedora (like Docker, Vagrant, DevAssistant, etc.)
- other tools which can be used for development
All portal is located on GitHub here [3].
Git repo with website, CSS and rest of stuff, is here [4].
Git repo for contents is here [5].
There were already several blog posts like [7][8].
I am glad to thank you also Adam Samalik, Josef Stribny for cooperation.
[1] https://fedorahosted.org/fedora-infrastructure/ticket/4876
[2] http://developer.fedorainfracloud.org/
[3] https://github.com/developer-portal/
[4] https://github.com/developer-portal/website
[5] https://github.com/developer-portal/content
[6] https://fedoraproject.org/wiki/Websites/Developer
[7] http://blog.samalik.com/fedora-developer-portal-prototype/
[8] http://phracek.livejournal.com/1403.html
--
Petr Hracek
Software Engineer
Developer Experience
Red Hat, Inc
Mob: +420777056169
email:phracek@redhat.com
--
Petr Hracek
Software Engineer
Developer Experience
Red Hat, Inc
Mob: +420777056169
email: phracek(a)redhat.com
8 years, 5 months
To distro-sync or not distro-sync?
by Miroslav Suchý
I am trying to upgrade to F23 (I know still not finished but...)
In past I always done 'distro-sync'. Albeit with yum.
Now I tried:
dnf system-upgrade download --releasever=23 --distro-sync
dnf system-upgrade download --releasever=23 --distro-sync --best
dnf system-upgrade download --releasever=23 --distro-sync --best --allowerasing
And all of them fail. See below for full log.
On the other hand:
dnf system-upgrade download --releasever=23
succeed.
Actually most of the problem are caused by retired or obsoleted packages. E.g fedup-dracut or rubygem-celluloid (this
one reported as BZ 1275030).
My question is should we use --distro-sync at all? Are users supposed to remove obsoleted packages manually?
If I do not pass --distro-sync then some packages are not upgraded. E.g in my case after upgrade I have
grub2-tools-2.02-0.16.fc22.x86_64.
Full log of failures.
# dnf system-upgrade download --releasever=23 --distro-sync --best
cannot install both kernel-devel-4.2.3-300.fc23.x86_64 and kernel-devel-3.19.4-200.fc21.x86_64.
package rubygem-celluloid-0.15.2-2.fc22.noarch requires rubygem(timers) < 1.2, but none of the providers can be installed.
package rubygem-celluloid-0.15.2-2.fc22.noarch requires rubygem(timers) < 1.2, but none of the providers can be installed.
package fedup-dracut-0.9.2-1.fc22.x86_64 requires librpm.so.3()(64bit), but none of the providers can be installed.
package rpm-libs-4.12.0.1-12.fc22.x86_64 requires rpm = 4.12.0.1-12.fc22, but none of the providers can be installed
(try to add '--allowerasing' to command line to replace conflicting packages)
# dnf system-upgrade download --releasever=23 --distro-sync
Error: package rubygem-celluloid-0.15.2-2.fc22.noarch requires rubygem(timers) < 1.2, but none of the providers can be
installed.
package grub2-tools-1:2.02-0.23.fc23.x86_64 requires librpm.so.7()(64bit), but none of the providers can be installed
(try to add '--allowerasing' to command line to replace conflicting packages)
# dnf system-upgrade download --releasever=23 --distro-sync --best --allowerasing
Error: package rubygem-celluloid-0.15.2-2.fc22.noarch requires rubygem(timers) < 1.2, but none of the providers can be
installed.
package fedup-dracut-0.9.2-1.fc22.x86_64 requires librpm.so.3()(64bit), but none of the providers can be installed
--
Miroslav Suchy, RHCA
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
8 years, 5 months
update rawhide to mercurial 3.6?
by Neal Becker
I am proposing to update mercurial in rawhide to 3.6 (the current release).
This could cause temporary breakage of tortoisehg and hg-git. Any
objections?
8 years, 5 months
Self Introduction: Barry Scott
by Barry
I am the maintainer for a number of open sources projects:
PyCXX - C++ interface to python
PySVN - pythonic OO API to Subversion
PySVN Workbench QUI interface to Subversion
MEINC_Installer - allows python code to packaged into
executable for for Windows and Linux
I have been in software development for a long time on many OS
(Fedora, OpenBSD, FreeBSD, Windows and DEC-VMS) in a number
of languages (Python, C++, C, shell, Bliss32, Javascript).
I have worked on fixes for the Kernel, Xorg, Python, systemd,
KDE and KMyMoney.
I would like to see Workbench packaged for Fedora and I am
willing to be the Fedora Packager for Workbench.
Barry
8 years, 5 months