devel October 2014

devel@lists.stg.fedoraproject.org

232 participants
256 discussions

Firefox Gtk3 test package
by Martin Stransky 06 Nov '14

06 Nov '14

Hi guys, first $SUBJ is available at: http://stransky.fedorapeople.org/FirefoxGtk3/ It's just a src.spm and plugin support it not finished (don't browse youtube ;-)) but may work as a preview. I'll provide Fedora builds and repo later. ma.

18 58

Proposal for integration tests infrastructure
by Honza Horak 04 Nov '14

04 Nov '14

Fedora lacks integration testing (unit testing done during build is not enough). Taskotron will be able to fill some gaps in the future, so maintainers will be able to set-up various tasks after their component is built. But even before this works we can benefit from having the tests already available (and run them manually if needed). Hereby, I'd like to get ideas and figure out answers for how and where to keep the tests. A similar discussion already took place before, which I'd like to continue in: https://lists.fedoraproject.org/pipermail/devel/2014-January/193498.html And some short discussion already took place here as well: https://lists.fedoraproject.org/pipermail/env-and-stacks/2014-October/00057… Some high level requirements: * tests will be written by maintainers or broader community, not a dedicated team * tests will be easy to run on anybody's computer (but might be potentially destructive; some secure environment will not be part of tests) * tests will be run automatically after related components get built (probably by Taskotron) Where to keep tests? a/ in current dist-git for related components (problem with sharing parts of code, problem where to keep tests related for more components) b/ in separate git with similar functionality as dist-git (needs new infrastructure, components are not directly connected with tests, won't make mess in current dist-git) c/ in current dist-git but as ordinary components (no new infrastructure needed but components are not directly connected with tests) How to deliver tests? a/ just use them directly from git (we need to keep some metadata for dependencies anyway) b/ package them as RPMs (we can keep metadata there; e.g. Taskotron will run only tests that have "Provides: ci-tests(mariadb)" after mariadb is built; we also might automate packaging tests to RPMs) Structure for tests? a/ similar to what components use (branches for Fedora versions) b/ only one branch Test maintainers should be allowed to behave the same as package maintainers do -- one likes keeping branches the same and uses "%if %fedora" macros, someone else likes specs clean and rather maintain more different branches) -- we won't find one structure that would fit all, so allowing both ways seems better. Which framework to use? People have no time to learn new things, so we should let them to write the tests in any language and just define some conventions how to run them. Cheers, Honza

5 5

Multiple problems with multiple monitors
by Basil Mohamed Gohar 04 Nov '14

04 Nov '14

I've searched for bugs related to the specific problems I've been having, and I've not been able to find anything that describes what I'm seeing. I have an HP EliteBook 840 that also comes with an UltraDock, to which I've plugged-in two external monitors and I use in conjunction with the built-in laptop display. Issue #1: I use LUKS to encrypt my disk, and when I first start up the computer, after choosing the kernel to boot into in GRUB, the GUI prompt for the LUKS passphrase shows-up on the middle monitor, not the laptop's built-in display. I don't mind this when I have multiple monitors plugged-in, but when I boot-up without the external monitors, such as when I'm unplugged from the UltraDock, I now get NO GUI prompt for the LUKS passphrase. I can enter it, and I can see a text prompt if I hit ESC. I suspect its attempting to display on the now phantom, unplugged monitor. Note, it was never plugged-in during this cycle. The problem is, I don't even know what's instructing LUKS or the GUI prompt to display on any monitor, so I don't know where to go to debug this. Issue #2: When I undock my laptop while logged-in, Gnome Shell just crashes. When I redock after the laptop has been started when unconnected, one of the two external monitors start-up (the one connected by VGA), but not the one connected by a DisplayPort connection. And, recently (but not when I first started using this laptop with the dock, which was about a month ago), now when I start-up with the laptop docked and both external monitors connected, both external monitors will be active, but the built-in display will show nothing. Gnome Shell reports the built-in display is active, but will not display anything unless I deactivate it and reactivate it via the settings "Displays" utility. Issue #3: The monitor connected via DisplayPort display significant tearing and delay on the upper-right half of the screen in the form of a triangle taking-up half of the screen. Reading about displayport and tearing issues, I guess the idea that these were resolved in the past. I don't know if this is the same or something different. I don't mean to use devel as a bug reporting venue, but I think these issues are either related or I just don't know how to address them to make significant progress to fixing them. Any guidance is more than welcome. Thanks! -- Libre Video http://librevideo.org

2 4

Requiring all files in /usr to be world-readable?
by Andrew Lutomirski 04 Nov '14

04 Nov '14

I filed an FPC ticket: https://fedorahosted.org/fpc/ticket/467 Thoughts?

8 16

RE: Proposal for integration tests infrastructure
by John Dulaney 03 Nov '14

03 Nov '14

Some thoughts: >> Where to keep tests? a/ in current dist-git for related components >> (problem with sharing parts of code, problem where to keep tests >> related for more components) b/ in separate git with similar >> functionality as dist-git (needs new infrastructure, components are >> not directly connected with tests, won't make mess in current >> dist-git) c/ in current dist-git but as ordinary components (no new >> infrastructure needed but components are not directly connected >> with tests) >> >> How to deliver tests? a/ just use them directly from git (we need >> to keep some metadata for dependencies anyway) b/ package them as >> RPMs (we can keep metadata there; e.g. Taskotron will run only >> tests that have "Provides: ci-tests(mariadb)" after mariadb is >> built; we also might automate packaging tests to RPMs) To answer both of these, the plan is to keep taskotron tasks in their own git repo; currently this is at (0). To run the tasks, taskotron sets up a disposable task client and then git clones the task to be run. This solves the issue of delivery and allows a continuous integration-like solution. >> Structure for tests? a/ similar to what components use (branches >> for Fedora versions) b/ only one branch Test maintainers should be >> allowed to behave the same as package maintainers do -- one likes >> keeping branches the same and uses "%if %fedora" macros, someone >> else likes specs clean and rather maintain more different branches) >> -- we won't find one structure that would fit all, so allowing both >> ways seems better. This is something we'll need to figure out, but, I suspect git branches will be involved. >> Which framework to use? People have no time to learn new things, so >> we should let them to write the tests in any language and just >> define some conventions how to run them. You'll need to at least define the task in a yaml file, and output will need to be TAP. The example task is at (1). > TAP (Test Anything Protocol) FTW. It really makes sense when you're > trying to combine tests from multiple different languages, testing > frameworks, etc. > > Stef > Indeed, which is why we settled on it. John. (0) https://bitbucket.org/fedoraqa (1) https://bitbucket.org/fedoraqa/task-rpmlint

2 1

possibly problem with rawhide (systemd-217?): "Found ordering cycle on basic.target/start"
by Matthew Miller 31 Oct '14

31 Oct '14

Updated my rawhide system. Now it doesn't boot cleanly. Will try to figure out the details in the morning (long week!), but "Found ordering cycle on basic.target/start" seems to be part of it, and I wanted to see if anyone else is hitting this (and possibly caution care on upgrading right now). Note "Breaking ordering cycle by deleting job sysinit.target/start". The system partially comes up, but there is a _lot_ of failure-to-work afterwards - probably related. Not positive it was the systemd update, or possibly some other unit file, or something else altogether. Will dig deeper after some sleep. :) -- Logs begin at Mon 2014-06-02 17:02:01 EDT, end at Thu 2014-10-30 21:40:54 EDT. -- Oct 30 21:39:37 ubik.home.mkmiller.org systemd[1]: Configuration file /usr/lib/systemd/system/auditd.service is marked world-inaccessible. This has no effect as configuration data is accessible via APIs without restrictions. Proceeding anyway. Oct 30 21:39:38 ubik.home.mkmiller.org systemd[1]: Cannot add dependency job for unit ksm.service, ignoring: Unit ksm.service failed to load: No such file or directory. Oct 30 21:39:38 ubik.home.mkmiller.org systemd[1]: Cannot add dependency job for unit ksmtuned.service, ignoring: Unit ksmtuned.service failed to load: No such file or directory. Oct 30 21:39:38 ubik.home.mkmiller.org systemd[1]: Cannot add dependency job for unit systemd-readahead-collect.service, ignoring: Unit systemd-readahead-collect.service failed to load: No such file or directory. Oct 30 21:39:38 ubik.home.mkmiller.org systemd[1]: Cannot add dependency job for unit systemd-readahead-replay.service, ignoring: Unit systemd-readahead-replay.service failed to load: No such file or directory. Oct 30 21:39:38 ubik.home.mkmiller.org systemd[1]: Found ordering cycle on basic.target/start Oct 30 21:39:38 ubik.home.mkmiller.org systemd[1]: Breaking ordering cycle by deleting job systemd-update-utmp.service/verify-active Oct 30 21:39:38 ubik.home.mkmiller.org systemd[1]: Job systemd-update-utmp.service/verify-active deleted to break ordering cycle starting with basic.target/start Oct 30 21:39:38 ubik.home.mkmiller.org systemd[1]: Found ordering cycle on basic.target/start Oct 30 21:39:38 ubik.home.mkmiller.org systemd[1]: Breaking ordering cycle by deleting job auditd.service/start Oct 30 21:39:38 ubik.home.mkmiller.org systemd[1]: Job auditd.service/start deleted to break ordering cycle starting with basic.target/start Oct 30 21:39:47 ubik.home.mkmiller.org systemd[1]: Found ordering cycle on basic.target/start Oct 30 21:39:47 ubik.home.mkmiller.org systemd[1]: Breaking ordering cycle by deleting job sysinit.target/start Oct 30 21:39:47 ubik.home.mkmiller.org systemd[1]: Job sysinit.target/start deleted to break ordering cycle starting with basic.target/start Oct 30 21:39:54 ubik.home.mkmiller.org systemd[1]: iptables.service: main process exited, code=exited, status=1/FAILURE Oct 30 21:39:54 ubik.home.mkmiller.org systemd[1]: Failed to start IPv4 firewall with iptables. Oct 30 21:39:54 ubik.home.mkmiller.org systemd[1]: Unit iptables.service entered failed state. Oct 30 21:39:54 ubik.home.mkmiller.org systemd[1]: iptables.service failed. Oct 30 21:39:56 ubik.home.mkmiller.org systemd[1]: Configuration file /usr/lib/systemd/system/wpa_supplicant.service is marked executable. Please remove executable permission bits. Proceeding anyway. Oct 30 21:40:01 ubik.home.mkmiller.org systemd[1]: Unit squid.service cannot be reloaded because it is inactive. Oct 30 21:40:01 ubik.home.mkmiller.org systemd[1]: Unit iscsi.service cannot be reloaded because it is inactive. Oct 30 21:40:04 ubik.home.mkmiller.org systemd[1]: docker.service: main process exited, code=exited, status=1/FAILURE Oct 30 21:40:04 ubik.home.mkmiller.org systemd[1]: Failed to start Docker Application Container Engine. Oct 30 21:40:04 ubik.home.mkmiller.org systemd[1]: Unit docker.service entered failed state. Oct 30 21:40:04 ubik.home.mkmiller.org systemd[1]: docker.service failed. Oct 30 21:40:11 ubik.home.mkmiller.org systemd[1]: Unit iscsi.service cannot be reloaded because it is inactive. Oct 30 21:40:11 ubik.home.mkmiller.org systemd[1]: Unit squid.service cannot be reloaded because it is inactive. Oct 30 21:40:11 ubik.home.mkmiller.org systemd[1]: Unit iscsi.service cannot be reloaded because it is inactive. Oct 30 21:40:11 ubik.home.mkmiller.org systemd[1]: Unit squid.service cannot be reloaded because it is inactive. -- Matthew Miller <mattdm(a)fedoraproject.org> Fedora Project Leader

7 27

5tFTW: Fedora Beta, Council & Elections, Strategic Planning, Outreach Committee, and FUDCon Reports (2014-10-31)
by Matthew Miller 31 Oct '14

31 Oct '14

Reposted from <http://fedoramagazine.org/5tftw-2014-10-31/>. Fedora is a big project, and it’s hard to keep up with everything that goes on. This series highlights interesting happenings in five different areas every week. It isn’t comprehensive news coverage — just quick summaries with links to each. Here are the five things for October 31st, 2014: Fedora Beta due Next Week ------------------------- I’ll keep this item short: Fedora 21 Beta is Go, and will be available Tuesday, November 4th. Next week, we’ll do an all-beta 5tFTW. This puts the final release target at December 9th. As always, these targets are more like guidelines than deadlines, but as we are verging on the holiday season we are going to make extra effort to avoid further adjustment. * https://lists.fedoraproject.org/pipermail/devel-announce/2014-October/00145… * http://fedoraproject.org/wiki/Releases/21/Schedule * https://www.youtube.com/watch?v=6GMkuPiIZ2k Council Update and Elections ---------------------------- The Fedora Council — our new top-level leadership body — includes two of seats appointed by elected committees and two seats elected by the Fedora Contributor community at large. The appointed seats covering Fedora Engineering and Fedora Outreach (more on that below) are now filled, by Josh Boyer and Christoph Wickert respectively. (Congratulations and thank you to Josh and Christoph!) Now it’s time to fill the elected seats — see the schedule announcement for details. Quick summary: nomination period next week; “campaign” week after that, and finally a week for community voting after that. The Council will take over from the Fedora Project Board when this is complete. * https://fedoraproject.org/wiki/Council * https://lists.fedoraproject.org/pipermail/announce/2014-October/003236.html * http://fedoraproject.org/wiki/Board Fedora Objectives ----------------- If you haven’t seen it already, I would like everyone who cares about what Fedora does and where the project is going to take a look at my recent Fedora Magazine article about Fedora objectives — why, how, and eventually what. As I mentioned a few weeks ago, high-level strategy discussions can feel disconnected and pointless. This is a process by which we can actually connect them into what we’re doing in a meaningful way, and by doing so increase the impact of our actions. Take a look, and take part in upcoming discussions on the public board discuss list. * http://fedoramagazine.org/lets-talk-about-fedora-project-objectives/ * https://lists.fedoraproject.org/pipermail/announce/2014-October/003235.html * https://admin.fedoraproject.org/mailman/listinfo/board-discuss Fedora Outreach Steering Committee? ----------------------------------- Fedora has long had two high-level elected steering committees, FESCo, the Fedora Engineering Steering Committee, and FAmSCo, the Fedora Ambassadors Steering Committee. The meritocratic representative positions on the Council are appointed by these committees. This is straightforward for the relatively wide-reaching FESCo, but the seat appointed by FAmSCo is actually intended to represent a much broader section of the project than ambassadors alone. This lead to a discussion about creating a new Outreach steering committee, tying together and coordinating efforts of Ambassadors, Marketing, Brand/Design, some aspects of the product Working Groups, Docs, various support channels — overall, all the parts of the project which are outward looking rather than focused on building the distro and infrastructure. Since FAmSCo has successfully delegated a lot of responsibility to regional ambassadors committees, and since the new Council will work on the high level community budget, this new body would make FAmSCo obsolete — so we’re not just piling on yet more committees, here! If you’re interested, join the new Fedora Outreach mailing list and let’s start building this! * https://fedoraproject.org/wiki/Fedora_Engineering_Steering_Committee * http://fedoraproject.org/wiki/Fedora_Ambassadors_Steering_Committee * https://lists.fedoraproject.org/mailman/listinfo/outreach Reports from FUDCon Managua --------------------------- As promised last week, some updates from FUDCon Managua, our user-and-developer conference held this year in Nicaragua. Check out reports from: - Alejandro Prez (Lots of pictures and people!) - William Moreno Reyes (In Spanish *and* English!) - Rino Rondan (All in Spanish, although the photographs are multilingual) - Robert Mayr (Just “day 0″ so far; check back for more updates from robyduck!) - Kiara Navarro (In Spanish with a lot of details, and again a lot of photos — and also, there’s part 2 and part 3) - Abdel G. Martínez L. (Particularly, highlights positive impact of the event on project contribution — nice!) - Daniel Bruno (In English) Thanks to everyone who made these reports, and thanks to the FUDCon LATAM organizers, and congratulations to everyone on yet another successful Fedora Premier Event! * https://fedoraproject.org/wiki/FUDCon:Managua_2014 * http://msvslinux1.blogspot.com/2014/10/fudcon-managua-2014.html * http://otroblogdegnu-linux.blogspot.com/2014/10/fudcon-managua.html * http://www.itrestauracion.com.ar/?p=2002 * http://robyduck.fedoraonline.it/?p=12 * http://panamahitek.com/fedora-users-developers-conference-managua-nicaragua… * http://panamahitek.com/fudcon-fedora-users-developers-conference-managua-ni… * http://panamahitek.com/fudcon-fedora-users-developers-conference-managua-ni… * http://www.abdelmartinez.com/2014/10/fudcon-managua-final-report.html * http://dbruno.org/fudcon-managua/ -- Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/> Fedora Project Leader mattdm(a)fedoraproject.org <http://fedoraproject.org/>

1 0

Self Introduction: Alexander Ploumistos
by Alexander Ploumistos 31 Oct '14

31 Oct '14

Hello everyone, I've decided to join the package maintainers and I would like to introduce myself. I have been a linux user since 2001 and a Red Hat/Fedora user since 2003. My main systems run on Fedora (of course) and Gentoo. I have a background in chemistry, particularly molecular modeling and for the past decade I have been working as a "general purpose IT guy" and part-time web-developer. I build systems, I design and deploy SOHO networks, I do some light pen-testing and provide tech support. I have experience coding in Fortran, Perl, PHP, Python, shell scripts, (X)HTML/CSS, I have worked with several CMSs -though in the past few years mostly with Joomla- and I have built some customized versions of embedded distros such as OpenWRT and other device-related software. During the past decade I have done alpha/beta/QA testing for a number of projects (most of them FLOSS) and I have provided translations and bug reports for others. I would like to give back something more than bug reports and translations and also improve my coding skills along the way. I have a couple of programs that I would like to maintain, but for the moment there remains an issue with their licenses. There is also a patched version of libatasmart, that takes care of an issue with several older Western Digital hard drives, that is awaiting review ( https://bugzilla.redhat.com/show_bug.cgi?id=1157150) and I would really appreciate it if someone could take the time to look into that. Best Regards Alexander

2 2

RHEL 6.6 MPI mess
by Dave Love 31 Oct '14

31 Oct '14

The undocumented openmpi and mpich updates in RHEL6.6 have broken binary compatibility and seem to be provoking general rebuilds of things in EPEL. While that may be OK for things that are packaged in EPEL, it at best doesn't help with our HPC users' locally-built programs or local/copr-published rpms (especially if the rebuilds involve their own ABIs incompatibilities, like scalapack currently in testing). It seems to me that the best approach, assuming Red Hat won't address the issue, is to supply compatibility packages in EPEL if that will work. I haven't had a chance to try, but I'll probably have to make something work eventually for openmpi, and presumably there are plenty of people in a similar situation. The updates are blocked by the dependencies of many installed packages here, but it will be increasingly awkward with packages that can't be updated without rebuilds. Has anyone tried that tack already, or is it clear it can't work for some reason?

4 5

[Base] Base Design WG agenda meeting 31 October 2014 15:00 UTC on #fedora-meeting
by Phil Knirsch 31 Oct '14

31 Oct '14

Agenda: - Status buildrequires cleanup work (davids & nils!) - Update on factory-reset work - Docker update - Phil on PTO for 3 weeks - Open Floor Thanks & regards, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Manager Core Services | Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch <pknirsch(a)redhat.com> Wankelstrasse 5 | Web: http://www.redhat.com/ D-70563 Stuttgart, Germany

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel October 2014