devel January 2016

devel@lists.fedoraproject.org

231 participants
286 discussions

Packaging of PlayOnLinux
by Jiří Konečný 03 Mar '16

03 Mar '16

Hello, I want to ask if PlayOnLinux could be packaged to Fedora. This program has list of proprietary programs which are not downloaded but could be installed if you give it setup.exe file. Also it downloads Windows redistributable when user explicitly wants to install program (which using this redist) or given redistributable. If this is not "legal" in terms of Fedora how it's differ from OpenSource software which are using not-OpenSource addons? Example of this could be https://marketplace.firefox.com . I think it's sad that this good LGPL wine prefix manager software is not part of the Fedora and I like to change this. Thank you for answers, Jirka Konecny

17 33

Seeking a package sponsor for Firefox Developer Edition
by Andrew Toskin 01 Mar '16

01 Mar '16

Hello! I'm interested in learning about RPM packaging for Fedora, and I'd like to see the "Developer Edition" release channel for Firefox (formerly called Firefox Aurora) available in the Fedora repositories. So my partner Bob and I are working on packaging firefox-dev. Our spec file repository is forked from the Fedora package for the regular release of Firefox. It's not in a working state yet, but you can see our progress on GitHub -- https://github.com/Bob131/firefox-dev/ And we have a Copr here -- https://copr.fedoraproject.org/coprs/bob131/firefox-dev/ Firefox Developer Edition and regular Firefox are able to share the same user profile (the bookmarks, preferences, etc) or use separate profiles, we're aiming to allow both versions of Firefox to coexist on the same system. Bob and I are both fairly new to the packaging process, so any help will be appreciated. Thanks, ~Andrew Toskin ("terrycloth" on GitHub and FAS)

2 1

Bugzilla "Fedora Components" group
by Richard W.M. Jones 26 Feb '16

26 Feb '16

I wonder if someone can remove the "Fedora Components" group from this bug. (I cannot do it). https://bugzilla.redhat.com/show_bug.cgi?id=1286432 It has the effect of making the bug private, which we don't want and didn't ask for. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW

3 10

kmods and Fedora
by Neal Gompa 22 Feb '16

22 Feb '16

Hello all, I've recently been wondering why we haven't allowed kernel module packages in Fedora since Fedora 8. I've tried searching through our wiki and the mailing list, but I haven't come up with any concrete reasons for why we disallow them. If it is perhaps the issue of keeping things in sync with kernels we provide (that is, maintainers didn't/couldn't keep up with new kernels being pushed during a release cycle), then I think the situation has changed. We have two tools that can help us in this regard: akmod and Koschei, both came after our policy change to disallow kernel modules. akmod is essentially DKMS except that instead of just building the kernel module, it'll build a kernel module package that matches an exact kernel release. Some of the weird problems that happen with DKMS don't seem to happen with akmod because of this. There's an argument for the akmod functionality being part of RPM and perhaps that should be the case. In any case, I don't see any particular reason akmod couldn't be brought into Fedora. On the other end, we have Koschei, which tracks and rebuilds things automatically (but doesn't submit automatically). It should be possible to adapt what Koschei does to be able to automatically generate new kmod packages tied to a particular kernel release and make it easy for a maintainer to turn that into something that can be submitted as part of a kernel update bundle to Bodhi. The biggest blocker I know of with kmods (at least dkms and akmod style ones) is we have a bug where DNF picks the wrong kernel-devel package at depsolve time[0] (this also appears to affect installing kernel-modules-extras too). Aside from the DNF issue, is there anything else I'm missing in relation to kmods in Fedora? Best regards, Neal [0]: https://bugzilla.redhat.com/show_bug.cgi?id=1228897 -- 真実はいつも一つ！/ Always, there's only one truth!

11 20

Orphaning The Mana World (tmw and tmw-music)
by Martin Gieseking 12 Feb '16

12 Feb '16

Hi, unfortunately, I have to orphan the two Mana World packages tmw [1] and tmw-music [2] since I don't use them any longer and don't have enough time to maintain them properly. It would be great if somebody is still interested in The Mana World and could take ownership. As far as I can tell, the code base of the currently packaged tmw client is outdated and should be updated to the recent system available at GitHub [3]. Martin [1] https://admin.fedoraproject.org/pkgdb/package/rpms/tmw [2] https://admin.fedoraproject.org/pkgdb/package/rpms/tmw-music/ [3] https://github.com/themanaworld

3 7

Intent to orphan shorewall
by Orion Poplawski 10 Feb '16

10 Feb '16

I'm planning on moving our firewall from a Fedora/shorewall system to a pfsense based one. Since I will no longer be using shorewall, I will be orphaning it. If you are interested in it, let me know and I would be happy to hand it off. -- 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

7 12

nss_myhostname as default in Fedora
by Orion Poplawski 08 Feb '16

08 Feb '16

See https://bugzilla.redhat.com/show_bug.cgi?id=1284323 as well For a while (from 197-1 until 228-5), systemd added "myhostname" to the end of the hosts line in /etc/nsswitch.conf in %post via sed. This has been removed as it is error prone, and the above request filed to add it by default to /etc/nsswitch.conf in glibc. The glibc maintainer would like to see discussion of this on the devel list, hence this email. My interest in this stems from build issues with mpich using programs. This may have been triggered by a combination of the above change as well as changes in mpich, I'm not sure. In any case, mpich uses gethostbyname() on the hostname of the machine it is running on in order to configure itself properly, and fails if it cannot do this. So the mpich tests run by netcdf are currently failing on the builders, and has since Nov 27 when systemd dropped adding myhostname took place. So: - Is the change to nsswitch.conf in glibc (back to behavior that was the default for quite a while) desired? - If not, is there some other way we can get the koji builders' mock configuration to be setup so they can at least resolve their own hostname? Thanks. PS - There is some other discussion around "mymachines" which seems much more problematic. I'd like to just focus on myhostname for now. The glibc maintainer has indicated that he wants to wait for mymachines to be resolved, but it's almost two months now and I don't see that being resolved soon. -- 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

13 29

In A World Where...TCs don't exist?
by Adam Williamson 07 Feb '16

07 Feb '16

Hi, folks! I thought this might be about the appropriate time to throw this out there. There hasn't been a big news press on this, but some of you may know that releng is fairly close to switching over to Pungi 4 for composes. For those of you who don't know: releng is fairly close to switching over to Pungi 4 for composes. This will have various interesting effects on QA and the whole process of building Fedora releases. With the current releng process, TC / RC composes are one beast, and nightly composes are another, very different beast. In fact nightly composes barely really 'exist' at all - when we say 'nightly compose' we really mean 'pungify the rawhide/branched repo, and fire off a bunch of koji tasks'. After the fact, there is no real relationship between any of those bits, which is why I had to write fedfind to go out and synthesize the concept of a 'nightly compose' by finding all the Koji tasks and treating them plus the repository boot.iso's as a single 'compose'. With Pungi 4, all composes will look a lot more similar. 'nightly' composes (which, in point of fact, will probably happen more than once per day - I'm not sure if we came up with a new name yet) look a lot more like current TC/RC composes than current nightly composes. You can see approximately what a Pungi 4 compose currently looks like here: https://kojipkgs.fedoraproject.org/compose/rawhide/ as of right now, the Koji built bits - lives, cloud and ARM disk images, etc - aren't integrated with the installer images, but they *will* be, and they'll all show up in the same location. As you can see it has all the different variants, and a Server DVD image. (A Pungi 4 compose also has a bunch of metadata, which means we can more or less kill off fedfind, thank God). The implication of this I wanted to talk about in this thread is: what does this mean for the release validation process, in terms of what composes we cut and what release validation events we have? So as you probably know, right now, the validation process is built around the milestone 'TC' and 'RC' images. We build a series of Alpha TCs and run a bunch of tests for each of these composes, reporting the results to wiki pages named for the composes. Then we do Alpha RCs, then Beta TCs, and so on through Final RCs. For the last few releases we've added on some 'nightly' validation events, where we create wiki pages named for nightly composes and run the same set of tests on the nightly boot.iso's and Koji images, but these have been framed as kind of an 'early warning system' for use before Alpha TC1 arrives, and once Alpha TC1 arrives we stop doing the nightly validation events. With Pungi 4, I don't think this makes a lot of sense any more. Dennis and I have been talking about this and I think we broadly agree on it. TCs and RCs used to be kinda the only way we *could* do validation testing. For long periods we didn't have reliable nightly builds of Rawhide or Branched at all, certainly not all the Koji-produced images. The process for doing 'real' composes was quite long and painful and required squishy human intervention. If we have automated, more-than-nightly composes that look much like a regular release compose would, there's no clear case for having TCs at all. We could simply stop building them and extend the "nightly" validation process. I think the way to do that would be to keep 'nominating' nightly composes for validation testing all the time, *except* when we're doing RCs. So instead of going something like: 24 Rawhide 20160120 24 Rawhide 20160215 == BRANCH POINT == 24 Branched 20160301 24 Branched 20160315 24 Alpha TC1 24 Alpha TC2 == ALPHA FREEZE == 24 Alpha RC1 24 Alpha RC2 == ALPHA RELEASE == 24 Beta TC1 .... we'd go something like: 24 Rawhide 20160120 24 Rawhide 20160215 == BRANCH POINT == 24 Branched 20160301 24 Branched 20160315 24 Branched 20160401 24 Alpha RC1 24 Alpha RC2 == ALPHA RELEASE == 24 Branched 20160501 24 Branched 20160515 24 Beta RC1 .... note: all dates completely made up, this is just for illustration. I think it would be plausible to do this for Fedora 24, if the Pungi 4 switchover happens soon and goes well. There would be some details to pin down in relval and wikitcms and stuff (we might need to tweak the validation event naming approach a bit so that it's possible to identify the sequence of events from the names - i.e. so you know where the RCs fit in), but nothing unsolvable. We'll be talking about a lot of this stuff at DevConf, if anyone's going to be there, pin down me or Dennis or someone else involved in release-y stuff and we'd be happy to discuss it. But I wanted to throw something up on the lists for discussion as well. What do you think? Thanks! One point that's come up already is the way that we manually pull newer packages to fix blocker/FE bugs into TC and RC composes via the 'bleed' repo. We're currently envisaging something like the 'buildroot override' mechanism for the compose process - some kind of system which would tag packages to be pulled into the composes somehow. It would still be gated through the blocker/FE review process at least during freezes, and probably all the time (it wouldn't be open season for any packager to request a 'compose override' at any time). This would also allow us to do stuff like 'tag new anaconda builds into the composes as soon as they land in updates-testing, so we can actually test them and provide karma'. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

6 8

DNF 1.0.1 Released
by Honza Silhan 04 Feb '16

04 Feb '16

The new release brings fixes of the most occurred errors in Fedora 22. Moreover adds SSL support in repository configuration and random sleep dnf-automatic feature. Read more in 1.0.1 release notes [1] on DNF documentation page, try it from testing and give it a karma. [1] http://dnf.readthedocs.org/en/latest/release_notes.html#id44 [*] http://dnf.baseurl.org/2015/06/12/dnf-1-0-1-released/ Honza by DNF team

9 20

qt (4) no longer injects $RPM_OPT_FLAGS by default (on f24+)
by Rex Dieter 03 Feb '16

03 Feb '16

In response to recent additions to default $RPM_OPT_FLAGS that depend on redhat-rpm-config to be present, and in response to bug http://bugzilla.redhat.com/1279265 Qt4's qmake will no longer inject $RPM_OPT_FLAGS any more, starting with qt-4.8.7-6.f24 Packages that use qmake will have to find some other mechanism, options include: 1. use %qmake_qt4 macro instead of calling qmake manually 2. set appropriate envrionment/qmake variables by hand 3. patch your buildsystem as needed 4. some better idea Please let me know if you have any questions about this. If any packages need fixing, I'd encourage bugs to be filed, and block bug #1279265 , and I'll make every effort to help fix things. Qt5 will likely follow suit soon. -- Rex

4 5

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel January 2016